Re: [rfc] Antimake

[Marko Kreen]

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