automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU make or portable make? (was: Makefile to Makefile.am)


From: Ralf Wildenhues
Subject: GNU make or portable make? (was: Makefile to Makefile.am)
Date: Tue, 17 Aug 2010 22:05:31 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

* Bob Friesenhahn wrote on Mon, Aug 16, 2010 at 05:06:40PM CEST:
> If depending on GNU make was considered ok, then Automake would have
> been developed quite differently than it is.  Given current Automake
> objectives, it is wise that individual projects also try to avoid
> GNU make syntax in Makefile.am.

While I don't dispute that, I do think that requiring GNU make is a
fairly low barrier in way of prerequisites.  GNU make is small, highly
portable and easily installed.  If Automake were only started now, I
think requiring GNU make would be a prudent design decision.

The current Automake code contains large chunks of logic that exists
purely to work around missing features or issues in non-GNU make
implementations.  Let's be honest, requiring GNU make outright would
make several optimizations possible, leading to smaller makefiles
and lower build system overhead.  We've been at the point before where
some new feature was easily implemented in GNU make syntax but rather
tough in portable make.  Some features may not be possible at all with
the latter.

Still, as things stand, I'm not sure whether changing design goals of
Automake now are such a good idea.  BSD developers really like using
their own make.  The code we have works, build system overhead is really
bad only on w32.  We have opportunities for improvement by assuming
Posix and XSI shell in more places, guarded by suitable tests.  As long
as the build system parallelizes well, I don't think there is too much
cause for concern.


For your own Makefile.am code, you can turn off warnings about
nonportable constructs by adding -Wno-portability to the automake
options.

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]