Another rant about alternative build systems that tries to be better than autotools, but end up being a whole mess. This time it’s the turn of qmake.
I decided to try cleaning up parallel make support in exscalibar, that’s currently forcing -j1 (thing that I don’t like at all, especially now that I have set up four distcc boxes for the iBook). So I start looking at it, and I find that it’s ignoring the dependencies that crosses directory boundaries, that’s right, make does not support them. But the order of SUBDIRS variable is correct.
Too bad I supposed it was using SUBDIRS as automake, considering it always ordered… instead it tries to parallelise the build in the various directories launching a job for each directory… but as it does not handle inter-directory dependencies, it screws up..
This is summarised in the title: if you want to be smart don’t try to be smart. Play it safe: default to ordered and then allow a “shuffled” option, not the other way around, sigh.
Another example of this can be found in scons, that for the sake of allowing a perfectly repeatable build does not consider the external environment. Too bad that it also ignores CC, CXX and PATH values, so packages using scons are most likely not making use of features like ccache or distcc.
Anyway, as a special gift to my users (:P) codeine now builds in parallel, respecting -j* and -s flags from MAKEOPTS, and supports distcc. Other packages I don’t use and I won’t lose time on fixing unless asked (and given a reason for why I should avoid fixing something else 😉 And exscalibar that builds parallel will come, too.
autofoo forever.
autofoo forever.Until someone smart manages to write something smarter and easier to use while not trying to be smart. Btw, you lied blatantly in previous post, grr. 😉
I’d like to have a good alternative to autofoo, but right now there are only sucky alternatives. One worse than the other.CMake is a bit better, but I think it’s still a bit rough for production use.