On Fri, Mar 09, 2012 at 11:11:56PM -0500, Sam Varshavchik wrote:
> Marko Kreen writes:
> >Antimake is my attempt to fix "no good build system" problem -
> >GNU Make library, but instead inventing custom conventions,
> >it implements Automake syntax.
> >
> >Example:
> >
> > bin_PROGRAMS = hello
> > hello_SOURCES = hello.c
> > include antimake.mk
> >
> >After writing such Makefile, you can run 'make' immediately,
> >no need for ./configure or Makefile rebuild.
>
> Woot.
>
> Did exactly the same thing myself, for my last $dayjob$. It turns
> out that GNU make macros can do pretty much everything that automake
> does.
>
> I started on 3.80, and it reached the point where the poor,
> suffering gmake was segfaulting on all the rules that were torturing
> it. Had to update it to 3.81, to actually get it to work.
Heh, same story here - initially I targeted 3.80, until it started
having random failures. I did some experiments to see whether I could
work around the problems but could not find any easy fixes (or even
exact cause), so I did not bother with 3.80 anymore.
> For extra credit, it should be possibly to hack this so that you can
> flip a switch and build both a "debug" build (-g for C/C++ code) and
> a "release" build (with -O2) at the same time. I did this by
> autogenerating two rulesets in parallel: something along the lines
> of one set of rules to build .o from C and C++ dot-extensions, and
> another rule to build .do from C and C++ dot-extensions, using the
> C/C++ build command with the right set of flags.
>
> Something like what libtool rules end up doing to build both static
> and shared libraries from the same set of source files.
>
> This also means two link targets, one to link the debug objects and
> one to link the release objects. Both for binaries and libraries;
> release binaries would link against the release libraries, and debug
> binaries would link against the debug libraries.
>
> So, in the above case, bin_PROGRAMS would expand out and define a
> target for both "hello" and "hello.debug", then write a dependency
> for each binary on the corresponding set of object modules, and the
> appropriate link command, then all the autogenerated rules take
> over, and build two sets of object modules in parallel, from the
> same list of source files. And with -j, everything was churning in
> parallel.
Antimake already has per-target object files so it should be easy
to add another level of indirection. But I wonder whether it's
actually necessary, as you can always do:
bin_PROGRAMS = foo
noinst_PROGRAMS = foo_debug
foo_SOURCES = ...
foo_CFLAGS = -O2
foo_debug_SOURCES = $(foo_SOURCES)
foo_debug_CFLAGS = -O0 -g
so why do you need additional magic for that?
> Those were the good ol' days…
Let bring 'em back ;)
--
marko
