Re: GNU make or portable make?

[Ralf Wildenhues]

Hi Tom,

* Tom Tromey wrote on Wed, Aug 18, 2010 at 12:21:19AM CEST:
> The "make" part of the build parallelizes well, but the configure part
> does not.

Yet.

> I think that is the big problem today.  It is particularly
> noticeable in big trees like gcc or gdb.

Both of whose build systems could use a bit of love, but yes, granted.

> GNU make could help solve this.  See quagmire for a random stab at this
> idea.  It isn't the most pleasant programming environment, but then
> neither is the m4+shell combination ;-).  I'm sure there are other
> workable approaches as well.

As much as I have sympathy with you for quagmire, I don't think it's the
way I would go (wouldn't have said so had you not brought it up ;-)
If one chooses to ditch the current system and start anew, I think it
should both be simpler to program in, and it should have the right
complexity for the edit-compile-test cycle even in very large trees,
which so far only tup[1] has, but that again doesn't fulfill a lot of
other needs.

But again, I don't think autoconf is at the end of the road in enabling
more Posix and XSI shell, nor have we seriously tried parallelism there
yet (but now we have experience from Autotest).

Cheers,
Ralf

[1] 

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

[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?

[Bob Friesenhahn]

On Tue, 17 Aug 2010, Tom Tromey wrote:


"Ralf" == Ralf Wildenhues  writes:


Ralf> If Automake were only started now, I think requiring GNU make
Ralf> would be a prudent design decision.

Yeah.  Portability looked a lot more important back then.  Nowadays I
think assuming GNU make is completely reasonable.  You can probably even
dig up cases where the configury for a project is bigger than GNU make
itself... you could shrink some programs by shipping the build tool :-)


If there is thinking to require GNU make, then there should be a bit 
more thinking as well.  A specialized mini-shell intended to run 
configure scripts and perform substitutions would be quite useful.  It 
would eliminate the shell portability issue and eliminate the need to 
fork to perform functionality like 'sed'.  The current approach 
requires that each package provide full configure/build capability 
using only portable aspects of tools and with no special build 
software (e.g. m4 macros) already installed on the system.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: GNU make or portable make?

[Tom Tromey]

> "Ralf" == Ralf Wildenhues  writes:

Ralf> If Automake were only started now, I think requiring GNU make
Ralf> would be a prudent design decision.

Yeah.  Portability looked a lot more important back then.  Nowadays I
think assuming GNU make is completely reasonable.  You can probably even
dig up cases where the configury for a project is bigger than GNU make
itself... you could shrink some programs by shipping the build tool :-)

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

The "make" part of the build parallelizes well, but the configure part
does not.  I think that is the big problem today.  It is particularly
noticeable in big trees like gcc or gdb.

GNU make could help solve this.  See quagmire for a random stab at this
idea.  It isn't the most pleasant programming environment, but then
neither is the m4+shell combination ;-).  I'm sure there are other
workable approaches as well.

Tom

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

[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)

[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