Re: [rfc] Antimake

[Marko Kreen]

On Sat, Mar 10, 2012 at 08:54:00AM +0100, Stefano Lattarini wrote:
> On 03/09/2012 11:26 PM, Marko Kreen wrote:
> > 
> > Antimake is my attempt to fix "no good build system" problem -
> > GNU Make library, but instead inventing custom conventions,
> > it implements Automake syntax.
> >
> JFTR, we've recently started a (low-priority) fork of Automake aimed at
> taking more advantage of GNU make features, with the hope of simplifying
> Automake and make it more manageable for both users and maintainers:
> 
>  <https://lists.gnu.org/mailman/listinfo/automake-ng>
>  
> <http://git.savannah.gnu.org/gitweb/?p=automake.git;a=shortlog;h=refs/heads/ng/master>

Great.  I hope Antimake gives you some inspiration what can be done.

> Can I ask with what license are you distributing your project?  If it's
> GPL-compatible, I'd be very happy to re-use some your code in Automake-NG
> (assuming they are not too radically different) ...

ISC, but I guess you can take any snippets from there as public domain.
I'm not especially proud of any hacks there, instead most of them feel
like workarounds for make deficiencies.

More complex hacks there seem to show what areas are weak in GNU Make
and need to be implemented in Make itself (eg JoinPath).


Hmm.  Now that I think about it, biggest deficiency seems to be missing
concept of (system-level) incude path for makefile fragments.  That
makes hard to have "standard make library" in system and simply do:

  include automake.mk

in Makefile and expect that users can do same as well.   I've worked
around that in Antimake with regular PATH - you can make antimake.mk
executable and put into PATH, then do:

  include $(shell antimake.mk)

but that does not feel like general solution to the problem.  But it's
big help for small private projects that can be compiled immediately
after writing Makefile without bothering copying antimake.mk.

> Anyway, I'm glad I'm not the only one interested in the "let's just require
> GNU make and live happily" approach!

Yeah, there really is no alternative in sight, especially when considering
portability, and whether it's already there...


I guess the main point I'm making with Antimake is that considering
now GNU Make 3.81 as base, we can have easily usable build system that:

- Provides Automake syntax
- Provides fully-featured build process (per-target objects, nice output, deps)
- Does not need to "build" makefiles
- Does not need autoconf setup before developer can compile a .c file 

It would be really cool if Automake 2/NG would also aim at this
directon.

-- 
marko