Re:Tup – an instrumenting file-based build system
by aidenn0 on Tuesday August 16, 2022 @01:50PM
(#32486298)
Include files are fine; in fact tup automatically handles that for static headers (i.e. header files that aren't generated as part of the build process).
One example of what I'm talking about is what another commentor mentioned: .java files will generate separate .class files for each inner-class in the file, so given "foo.java" you can't tell which .class files will be output when compiling "foo.java" without looking at the contents of "foo.java"
I actually originally had a Makefile with predeps/build/install targets where the "build" step just called tup. People complained that "if tup is supposed to replace make, why are you using make?" I switched it to predeps.sh/build.sh/install.sh and everybody shut up. I personally think it's less ergonomic but don't care enough to argue with a different person every week.
Re:Tup – an instrumenting file-based build system
by maccard on Tuesday August 16, 2022 @03:07PM
(#32487328)
> I personally think it's less ergonomic but don't care enough to argue with a different person every week.
I'm with you here!
> There are also various limitations, caveats, &c. such that I typically had a "build.sh" or some-such that did any necessary pre-tup work.
Frankly if I need to write custom wrapper scripts for a build system then the build system isn't up to scratch. On every project I work on, you can run
To get a list of targets, and build/install/predeps/deploy are all defined. On any of of our projects, make predeps && make build will output a deployable binary.> Calculating this outside of tup is fine even if it's expensive, as long as it changes rarely.
So no include files? That's another deal-breaker!