You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As seen here: #17 (comment)
I wrote a small script which will serially spawn bzlgen to write build files for our whole repository.
I think it would be worth while feature to upstream this functionality.
To speed this up we could also implement concurrent file generation, to do this we'd simply need to adjust commands.txt so it gets a unique name per instance.
This could also be extended later to include other feattures like watch mode and running as a daemon process.
But for the first instance being able to run over multiple first would make inital migrations to use this easier.
The text was updated successfully, but these errors were encountered:
Toxicable
changed the title
[feat] whole repositry file gen
[feat] whole repository file gen
Feb 3, 2020
buildozer is very efficient with processing the commands, we probably want to just create one commands file still (a few 1000 buildozer commands take < ~3s to run in my experience).
I'm wondering what level of granularity to generate? (treat all folders with no subfolders as the final generation target?).
Ah right! if we could generate a commands.txt which could do the whole repository at once im sure that would do the trick. I'm not familar with buildozer so not familar with what it has avilable.
For granularity I think we generate a build file per directory that has source files.
I think to be flexible we'd want to provide an api where users can give their own list of dirs. Maybe this is a throug a glob, for examples we'd want to generate files in apps/* and libs/*
We're definately keen on a watch mode also, it would be pretty bad DX running your process with ibazel but having to manually run build file generation on each save also
As seen here: #17 (comment)
I wrote a small script which will serially spawn bzlgen to write build files for our whole repository.
I think it would be worth while feature to upstream this functionality.
To speed this up we could also implement concurrent file generation, to do this we'd simply need to adjust commands.txt so it gets a unique name per instance.
This could also be extended later to include other feattures like watch mode and running as a daemon process.
But for the first instance being able to run over multiple first would make inital migrations to use this easier.
The text was updated successfully, but these errors were encountered: