gittup
Integration of subprojects of other build systems
I have used Tup successfully for a bare-metal, microcontroller-based project. I am trying to use Tup as the foundation to create a BSP (board support package) for an embedded Linux project and make it serve the similar purpose as Buildroot or Yocto/OpenEmbedded, but in a much simpler manner. Unlike the microcontroller project, embedded Linux systems depend on a bunch of large third-party codebase which have their own complex build infrastructures that are too time consuming and error-prone to convert to Tupfile. The solution I came up with is to treat the build commands of those subprojects as normal generation commands in Tup. So I could handle it like
: |> !my-linux-build-script |> $(LINUX_BUILD_OBJDIR)/vmlinux.elf | ^$(LINUX_BUILD_OBJDIR) # The whole output directory should be ignored by Tup
This seems to work to an extent.
The shortcoming is, Tup has all the stdout/stderr of the executed command buffered and will only output it when the command exits. The build logs will be blocked for tens of minutes or longer.
Can Tup have a ^-flag such as 'v' (stands for verbose) or something else to indicate piping out the stdout/stderr transparently? Or maybe there is more sensible approach?
If your plan is to ignore all the file accesses anyway, might it make more sense to use make for that level of your project? In other words, instead of having tup call out to a bunch of make subprocesses, you could have make call out to make & tup subprocesses. Tup will add some overhead to track the file accesses, though how much exactly can depend on what the subprocesses do. Since you're dropping all that information, you might just want to not collect it in the first place by using make.
Of course I don't have the full context of your project (I've used buildroot, but probably 10-15 years ago?) so that might not work with the rest of your Tupfiles. All that said, I think the ^-flag to not buffer things is a good idea, though I've called it "streaming mode" and used ^s, since "verbose" is already a command-line flag that has a slightly different meaning. So pull the latest and try putting in some ^s's around and let me know if you run into any issues with it.
