On Sat, Mar 10, 2012 at 01:08:01PM -0500, Sam Varshavchik wrote: > Actually, my hack was even more generic, and allowed turnkey custom > definition of arbitrary build modes. > > BUILDMODES=prod > > was the default. > > BUILDMODES=prod debug > > was the release+debug build. A rule foreach-ed over BUILDMODES, > eval-ing a rule with each word as a parameter, and generating target > rules using $(1)_CFLAGS, $(1)_CXXFLAGS, i.e. prod_CFLAGS, > debug_CFLAGS, and so on. So, someone could define a custom build > mode called "funky", define funky_CFLAGS, et al, and produce a set > of binary targets built with the funky flags, in addition to the > stock release and debug compilation options.
That's sounds pretty nice, it seems to be really useful for situations where you need to build for different arches, 64/32-bit or simply with different optimizaion flags. I already have urge to implement it for Antimake too. Except, the sane part of my mind orders me to think that Antimake is not written in general programming language in "GNU Make language", which means any additonal features need to be dealt really carefully. It already does target copying for embedded subdirs, so perhaps that aspect can be generalized a bit. Another thing it contains is "Libusual embedding" which means automatic finding needed source files and adding them to target sources. This clearly does not belong to "antimake.mk", instead needs generic target-rewriting hooks. So I guess if it fits in with cleanup and generalization of existing code, it can be done, but otherwise its better to avoid anything that makes code even more complex. -- marko
