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

2010-08-17 Thread Robert J. Hansen
> I for one would be glad if automake required GNU make, since it
> could make use of a lot of useful features which currently aren't
> allowed.  Similar to autoconf not requiring a POSIX shell, depite
> the fact that non-POSIX shells are so far obsolete they are
> irrelevant.

Are there any tools to spot GNUisms in Makefiles?  If not, it seems like this 
would be a useful thing to develop.




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

2010-08-17 Thread Roger Leigh
On Tue, Aug 17, 2010 at 10:05:31PM +0200, Ralf Wildenhues wrote:
> * 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.

As someone who tried hard to keep their project's Makefiles portable
across all vendor make variants, I'd just like to point out that in
practice most projects end up dependent upon GNU make, even if that
wasn't their deliberate intention.  If your primary development
environment is GNU-based such as GNU/Linux, or even MSYS, your primary
testing is always with GNU make and non-portable things won't be found.

I spent a lot of time making sure BSD and Solaris makes worked
correctly, but unless you've got people testing every release against
all other makes, GNU make-isms gradually creep back in.  In my case
the cost of the testing was not worth the benefit--no one else was
using those platforms regularly enough and we ended up simply
mandating GNU make in any case.  A similar story has played out for
all of the projects I've been involved with: while in theory automake
produces portable Makefiles, in practice they are not.  The reality
was that for the odd single user using BSD who ran into problems, the
answer was just to build with gmake.

I for one would be glad if automake required GNU make, since it
could make use of a lot of useful features which currently aren't
allowed.  Similar to autoconf not requiring a POSIX shell, depite
the fact that non-POSIX shells are so far obsolete they are
irrelevant.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature


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

2010-08-17 Thread Ralf Wildenhues
* 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