Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Bruno Haible]

Richard Stallman wrote:
> one GNU package could drop support for ordinary Make, and see
> how users react.  If the level of complaint is not too high, then
> another GNU package could do this.  Once many GNU packages have done
> this, we might conclude it is ok for all GNU packages to do so
> (perhaps with a few exceptions).

Joseph Myers already mentioned GCC.

GNU coreutils require GNU make at least on AIX and OSF/1 [1][2].
The need for GNU make is now documented.

CLN (not a GNU package) needs GNU make and documents this requirement
very prominently in the installation instructions. As far as I can remember,
no single user has every complained about it.

When I needed to install GNU make on platforms such as AIX and OSF/1,
it was done in 5 minutes, because the released tarball has no external
dependencies and was well tested.

Bruno

[1] http://lists.gnu.org/archive/html/bug-coreutils/2007-02/msg00241.html
[2] http://lists.gnu.org/archive/html/coreutils/2011-09/msg00122.html
-- 
In memoriam Gavriel Holtzberg 

RE: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[John Calcote]

> > Rather, one GNU package could drop support for ordinary Make, and
see
> > how users react.  If the level of complaint is not too high, then
> 
> GCC dropped support for non-GNU make in version 3.4 (April 2004).
> 
> We could see how users reacted to that.

Forgive my ignorance (because I'm *sure* I'm missing something crucial
here), but I don't believe this is a fair comparison, since GCC's use of
make doesn't appear (to me) to be in the same order as Automakes use of
make.

Regards,
John

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Richard Stallman]

> Rather, one GNU package could drop support for ordinary Make, and see
> how users react.  If the level of complaint is not too high, then

GCC dropped support for non-GNU make in version 3.4 (April 2004).

We could see how users reacted to that.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Joseph S. Myers]

On Tue, 22 Nov 2011, Richard Stallman wrote:

>   1. We start requiring GNU make in an "experimental" automake 2.0
>development line (which might, and will, break whathever
>backward-compatibility gets in its way).
> 
> If we want to experiment with this, we should not do so in Automake!
> 
> Rather, one GNU package could drop support for ordinary Make, and see
> how users react.  If the level of complaint is not too high, then

GCC dropped support for non-GNU make in version 3.4 (April 2004).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Richard Stallman]

Honestly, there are such users today?  I mean, almost every Unix newbie
these days either:

 - installs a Linux distro,

Do you mean a GNU/Linux distro?  If it is Linux alone, it won't even run.

The practice of ignoring the GNU Project (us!) and calling the GNU
system "Linux" hurts our work, so please make an effort to learn a
different habit.

Meanwhile, GNU newbies are not "Unix newbies" because GNU's Not Unix.

Anyway, rather than making speculative arguments about what users
want, let's find out -- by asking thenm and by small experiments,

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Nick Bowler]

On 2011-11-22 20:33 +0100, Stefano Lattarini wrote:
> On Tuesday 22 November 2011, Nick Bowler wrote:
> > On 2011-11-22 17:46 +0100, Stefano Lattarini wrote:
> > > See also:
> > >   
> >
> > Yes, it is sad that many package maintainers fail to properly test their
> > build systems.
>
> Consider that some maintainers cannot; not everyone can afford to have
> access to all the *BSD, as well as Solaris, AIX, Windows (for Cygwin) ...

Obviously, it's going to be harder to test some platforms than others.
And it's obviously impossible to test every possible environment.  But
what maintainers can and should do is test their packages in as many
different environments as is feasible.

There is a wonderful free software package called Qemu, which allows
one to pretty easily test at least {Free,Net,Open}BSD and OpenSolaris.
Qemu also supports a number of CPU architectures (useful for testing
CPUs that you don't have access to; not so important for testing the
build system, though).

In terms of testing make implementations, GNU make, bmake/pmake (both
ports of NetBSD make), dmake and heirloom make are free software and
easily available for GNU/Linux systems (please let me know if I missed
any!)

Microsoft Windows can be problematic to test because it is proprietary
software, but there's another free software package called Wine that
gets you 90% of the way.  I use an i486-pc-mingw32 cross toolchain for
this purpose: this has the advantage of simultaneously testing my cross
toolchain support.  Unfortunately, wine seems to have some troubles with
Cygwin, though there are success stories.

If you use libtool, you can configure with --disable-shared which will
give you a pretty good idea of how your package will work on platforms
without shared libraries.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefano Lattarini]

On Tuesday 22 November 2011, Bob Friesenhahn wrote:
> On Tue, 22 Nov 2011, Stefano Lattarini wrote:
> 
> >> In order for this to work, Automake would need to become self-hosting
> >> (not need other packages to be installed in advance) and written only
> >> in a GNU-approved and FSF-copyrighted portable implementation
> >> language.
> >>
> > Honestly, my idea was to follow the "lead" of Quagmire here, and use
> > GNU make's own "extensibility" ($(eval), $(call), self-reflection
> > features like $(.VARIABLES), etc.) as a leverage.  If we don't, we'd
> > better try to create a new-generation build system instead, as you've
> > proposed.
> 
> I would like to use a build system which maintains a formal record of 
> input files used, as well as their signatures, so that the software is 
> properly built even if a file is set back in time (e.g. replaced with 
> an older version).  I would also like to use a build system which 
> intelligently avoids unnecessary re-linking of objects and libraries 
> but always re-links when needed.  I would like to use a build system 
> which can intelligently distribute builds across multiple machines if 
> necessary.  Can pure GNU make syntax be used to accomplish all that?
>
I honestly don't know.  But I *guess* that, if it can, it would require
a lot of work, and probably a lot of hacks.

> > That sounds like a too grand, over-reaching plan to me; and its very
> > concept seems to be somewhat at odds with the Unix philosophy.
> 
> How so?  It is true that Kernighan & Pike recommend simplicity but 
> they don't recommend inefficiency either.  Today the GNU build system 
> suffers from considerable inefficiency and a huge amount of 
> complexity.
>
Sadly true.  Starting to take advantage of GNU make might help in
mitigating this.  Or maybe this is just wishful thinking; we won't
know until we try it out.

> If GNU is willing to require that a GNU build tool be 
> installed in advance, then that build tool should be the best
> fit for the actual requirements as possible.
>
But GNU make is not a "random" GNU tool -- it's a mature, well-known,
alredy widespread tool, already used and required by non-trivial
build systems (e.g., Linux kernel's, and git's).

> In autotools, great effort is made to try to write shell, sed, awk, 
> and m4 code which works portably across many implementations
>
[micro-nit: this is not the case anymore for the m4 code, which has
 been since long requiring GNU m4]

> and requires a great many fork/exec calls and opening, reading, writing, 
> and closing of files.  If GNU is to require installing a build tool 
> then that build tool should entirely eliminate any need to worry about 
> syntax portability so that scripts can be written to do exactly what 
> is required.
>
Again, I'm not opposed to the idea (which might have a large acceptance
after all, judging from CMake success).  But I find it ortoghonal to
the proposal under discussion, which has a much narrower and less
"speculative" scope (note that "speculative" is to be intended in its
good sense here!).

Regards,
  Stefano

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefano Lattarini]

On Wednesday 23 November 2011, Dave Hart wrote:
>
> [HUGE MEGA SNIP]
>
> I like RMS's idea of switching one or two GNU packages to require GNU
> make to test the waters.  Obviously, GNU make itself needs to require
> only portable make to enable bootstrapping.
>
If I'm not mistaken, GNU make doesn't even require any make program in
order to bootstrap -- it  comes with a shell script that can do the
initial build if no make program is found (as Paul Smith has pointed
out).

> I agree the experiment shouldn't be done first with Automake,
> as that would have implications for all packages uses Automake.
> Doing it with an Automake fork called Automire wouldn't be such
> a problem, but Stefano probably doesn't find forking appealing
> for a number of sound reasons.
>
In truth, given the feedback received, I think a fork would be not
only less controversial, but also much more appealing than a branch
in the automake repostory, which might cause automake and automire
to gets in each other's way.

> Thanks for the choice to support use of Automake by non-GPL packages,
> and for hearing the concerns of a maintainer of such a package.
> 
> Cheers,
> Dave Hart
> 

Thanks for the feedback,
   Stefano

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Dave Hart]

On Tue, Nov 22, 2011 at 16:46, Stefano Lattarini
 wrote:
> On Tuesday 22 November 2011, Nick Bowler wrote:
>> I think this discussion is for the most part ignoring what is (IMO) the
>> most important issue: it must be easy for ordinary (non-developer) users
>> to build free software packages!

Hear, hear!  My selfish agenda is to keep even the most ancient and
crusty systems able to build NTP tarballs with the minimum of
prerequisites.  This is why when sntp started using libevent, we
worked with the libevent maintainers to upstream changes to it making
it more suitable for source-level inclusion in dependent packages, and
we now have libevent in every NTP tarball.  If you have a
suitably-recent libevent installed, great, we use it, otherwise we
build our tearoff libevent as a static library and link against it.

Such a path is not feasible for GNU make.  If our distributions
require GNU make, we will be at the mercy of Automire/Automake 2 in
terms of finding and using existing GNU make when it is not called
"make".

Stefano has previously indicated packages which want to remain as
portable as possible could stick with Automake 1.x for at least
several years before Automake 1.x is no longer maintained in favor of
Automire/Automake 2, but no one likes to be stuck on a dead-end train.
 If you draw Automake maintainers' focus to Automake 2, you
simultaneously send a strong message that Automake 1.x is on its way
out, and will invite legitimate concerns about every future Automake
1.x's quality given the cool kids among the maintainers have all
switched focus to Automake 2.x.  Calling your Automake fork requiring
GNU make of tarball users Automire is much less dangerous to the
Automake brand, and it sends the message that the branch we're calling
Automake 1.x here, which targets portable make, is not necessarily
doomed to lack of maintenance within a few years.

>> This especially includes users who
>> have no idea that there's a difference between GNU make and the version
>> of "make" that is already on their system.
>>
> Honestly, there are such users today?  I mean, almost every Unix newbie
> these days either:
>
>  - installs a Linux distro, which comes with GNU make as the default
>   make program (and we're also ignoring the fact that most such
>   users will install stuff only through the distro's package manager
>   anyway, not from sources -- and I don't blame them for this!);
>  - is using Mac OS X, which comes with GNU make as the default make;
>  - installs Cygwin (or possibly MinGW/MSYS) or on his Windows system,
>   thus getting GNU make as the default make in the process.
>
> I expect a user of the *BSD systems (and even more of proprietay Unixes)
> will be learned enough to know the difference between the vendor make and
> GNU make.
>
> That said, having some layer that would allow common "make TARGET" commands
> to re-invoke themselves with GNU make (maybe with a proper warnings) would
> be worthwhile; but this would *not* be done for the benefit of the newbies,
> rather to help out the experienced-but-distracted(-or-lazy) user.
>
>> This is, I think, the single best way to encourage users to become more
>> involved in the free software community.  If the user can't easily build
>> a package, they won't test new versions and they won't test patches.
>>
> Seriously, a user experienced enough to try out a patch will not
> have a problem understanding the difference the vendor make and
> GNU make, and to act consequently.

Nick has already made this point pretty well, but I want to toss my
voice behind his:  Stefano's mental model of who might not already be
using GNU make or understand the difference between portable make and
GNU make is overly restrictive and doesn't admit scenarios important
to me in my quest to keep NTP tarballs buildable by as many people as
possible, including those whose 'make' is not GNU and those who would
have to build GNU make from source to have it available.

"newbies" aren't the only concern here -- there are plenty of people
using Automake-supported systems without the slightest developer
skills -- they are interested in using software, not changing or
writing software, in some cases.  They are "newbies" to Makefiles and
build infrastructure engineering for years after they are productive
sticking to their packages and ports systems.  When I ask them to see
if a problem they're having with their ntpd exists in
currently-maintained versions, they might never have built any
software from source, and they may not be using a system that ships
GNU make.

I am talking about tarball users, not developers.  I want to keep the
barrier as low as I can.  It is not acceptable to me to assume they
are naturally on their way to being software developers simply because
they are using a GNU-like system.  Similarly it is not true that
nearly all such 'newbies' in the last few years are using Linux or Mac
OS.  In the last few years, people who have reason to build ntpd from
source w

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefan]

unsubscribe

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Bob Friesenhahn]

On Tue, 22 Nov 2011, Stefano Lattarini wrote:


In order for this to work, Automake would need to become self-hosting
(not need other packages to be installed in advance) and written only
in a GNU-approved and FSF-copyrighted portable implementation
language.


Honestly, my idea was to follow the "lead" of Quagmire here, and use
GNU make's own "extensibility" ($(eval), $(call), self-reflection
features like $(.VARIABLES), etc.) as a leverage.  If we don't, we'd
better try to create a new-generation build system instead, as you've
proposed.


I would like to use a build system which maintains a formal record of 
input files used, as well as their signatures, so that the software is 
properly built even if a file is set back in time (e.g. replaced with 
an older version).  I would also like to use a build system which 
intelligently avoids unnecessary re-linking of objects and libraries 
but always re-links when needed.  I would like to use a build system 
which can intelligently distribute builds across multiple machines if 
necessary.  Can pure GNU make syntax be used to accomplish all that?



That sounds like a too grand, over-reaching plan to me; and its very
concept seems to be somewhat at odds with the Unix philosophy.


How so?  It is true that Kernighan & Pike recommend simplicity but 
they don't recommend inefficiency either.  Today the GNU build system 
suffers from considerable inefficiency and a huge amount of 
complexity.  If GNU is willing to require that a GNU build tool be 
installed in advance, then that build tool should be the best fit for 
the actual requirements as possible.


In autotools, great effort is made to try to write shell, sed, awk, 
and m4 code which works portably across many implementations and 
requires a great many fork/exec calls and opening, reading, writing, 
and closing of files.  If GNU is to require installing a build tool 
then that build tool should entirely eliminate any need to worry about 
syntax portability so that scripts can be written to do exactly what 
is required.


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

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefano Lattarini]

On Tuesday 22 November 2011, Bob Friesenhahn wrote:
> On Tue, 22 Nov 2011, Stefano Lattarini wrote:
> >>> there may be some benefit to package maintainers (hopefully by
> >>> making automake easier to use),
> >>>
> > My hope is to manage, in the *long* run (real long), to turn automake
> > (or more precisely, its purpoted GNU-make-based successor, let's call
> > it "automire") into something *truly* extensible -- I mean, something
> > like autoconf-extensible.  This would be a huge win for the package
> > maintainers.
> 
> In order for this to work, Automake would need to become self-hosting 
> (not need other packages to be installed in advance) and written only 
> in a GNU-approved and FSF-copyrighted portable implementation 
> language.
>
Honestly, my idea was to follow the "lead" of Quagmire here, and use
GNU make's own "extensibility" ($(eval), $(call), self-reflection
features like $(.VARIABLES), etc.) as a leverage.  If we don't, we'd
better try to create a new-generation build system instead, as you've
proposed.

> Currently Automake is written in perl, which is not a 
> GNU-approved or FSF-copyrighted language and is also something which 
> would need to be installed in advance.  If Automake was self-hosting 
> then there would be no need for distributing pre-generated template 
> files since Automake could generate everything it needs at run-time.
>
> It would be quite useful for a FSF project to be spun-up to create an 
> embeddable/small language interpreter and standard library which is 
> capable of efficiently implementing complex make-like functionality 
> ('automake') as well as providing functional replacements for any 
> necessary string processing currently provided by 'sed', 'awk', and 
> 'printf'.  The sole function of the interpreter would be to provide 
> the framework for building other software.  This intepreter could form 
> the basis for the new automake build tool.
>
That sounds like a too grand, over-reaching plan to me; and its very
concept seems to be somewhat at odds with the Unix philosophy.

Regards,
  Stefano

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Reuben Thomas]

On 22 November 2011 20:48, Bob Friesenhahn  wrote:
>
> It would be quite useful for a FSF project to be spun-up to create an
> embeddable/small language interpreter and standard library which is capable
> of efficiently implementing complex make-like functionality ('automake') as
> well as providing functional replacements for any necessary string
> processing currently provided by 'sed', 'awk', and 'printf'.  The sole
> function of the interpreter would be to provide the framework for building
> other software.  This intepreter could form the basis for the new automake
> build tool.

Or you could use Lua (www.lua.org) and give up the "GNU-copyrighted"
bit. Several projects (e.g. [1][2]) to produce customizable build
systems have already been written in Lua, so it seems to be suitable.
It's mature, small, fast and easily understood by users wanting to
customize a program based on it at any level, as the syntax is
Pascal-like and, being originally designed as a data description
language, configuration files (and makefiles) are conveniently
expressed directly in the language. Its core is pure ANSI C89 and also
pure C++ (it's written in the subset), so it'll build easily anywhere.
It's free software (MIT license). If in doubt, ship the Lua source
with the tool you're writing in it.

[1] http://jan.kneschke.de/projects/how-to-write-a-good-build-system/
[2] http://primemover.sourceforge.net/

-- 
http://rrt.sc3d.org

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefano Lattarini]

[Sorry for the late reply, I've received your message just now]

On Tuesday 22 November 2011, Olaf van wrote:
> I've been wondering, why not 'merge' the generator and the executor
> and consider the file format an implementation detail?
> 
> Olaf
> 
What do you mean with by "generator" and "executor" exactly?

Regards,
  Stefano

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Bob Friesenhahn]

On Tue, 22 Nov 2011, Stefano Lattarini wrote:

there may be some benefit to package maintainers (hopefully by
making automake easier to use),


My hope is to manage, in the *long* run (real long), to turn automake
(or more precisely, its purpoted GNU-make-based successor, let's call
it "automire") into something *truly* extensible -- I mean, something
like autoconf-extensible.  This would be a huge win for the package
maintainers.


In order for this to work, Automake would need to become self-hosting 
(not need other packages to be installed in advance) and written only 
in a GNU-approved and FSF-copyrighted portable implementation 
language.  Currently Automake is written in perl, which is not a 
GNU-approved or FSF-copyrighted language and is also something which 
would need to be installed in advance.  If Automake was self-hosting 
then there would be no need for distributing pre-generated template 
files since Automake could generate everything it needs at run-time.


It would be quite useful for a FSF project to be spun-up to create an 
embeddable/small language interpreter and standard library which is 
capable of efficiently implementing complex make-like functionality 
('automake') as well as providing functional replacements for any 
necessary string processing currently provided by 'sed', 'awk', and 
'printf'.  The sole function of the interpreter would be to provide 
the framework for building other software.  This intepreter could form 
the basis for the new automake build tool.


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

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Richard Stallman]

  1. We start requiring GNU make in an "experimental" automake 2.0
 development line (which might, and will, break whathever
 backward-compatibility gets in its way).

If we want to experiment with this, we should not do so in Automake!

Rather, one GNU package could drop support for ordinary Make, and see
how users react.  If the level of complaint is not too high, then
another GNU package could do this.  Once many GNU packages have done
this, we might conclude it is ok for all GNU packages to do so
(perhaps with a few exceptions).

Then we could deprecate use of Automake to make ordinary makefiles.
Later we could remove that support from Automake.

This is a slow, cautious process -- the way it should be.

> Maybe in the discussion we should distinguish GNU-like systems
> (perhaps including Mac OS)
>
Do you mean POSIX-like systems?

I mean GNU-like.  GNU is our main target, but if another system is
similar enough to GNU, support for it is not much extra work.
-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Olaf van der Spek]

I've been wondering, why not 'merge' the generator and the executor
and consider the file format an implementation detail?

Olaf

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefano Lattarini]

I hadn't answered to this part of Nick's mail before, allow
me to do it now ...

On Tuesday 22 November 2011, Bob Friesenhahn wrote:
> On Tue, 22 Nov 2011, Nick Bowler wrote:
> >
> > We must weigh the costs against the benefits.  It's currently not clear
> > to me what the benefits actually are, to anyone other than automake
> > maintainers.
> >
> > Currently, the benefits to automake maintainers is clear,
> >
And these, as I've already said, are my main motivation.

> > there may be some benefit to package maintainers (hopefully by
> > making automake easier to use),
> >
My hope is to manage, in the *long* run (real long), to turn automake
(or more precisely, its purpoted GNU-make-based successor, let's call
it "automire") into something *truly* extensible -- I mean, something
like autoconf-extensible.  This would be a huge win for the package
maintainers.

> > and there seems to be no benefit to users at all.
>

Regards,
  Stefano

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Bob Friesenhahn]

On Tue, 22 Nov 2011, Nick Bowler wrote:


We must weigh the costs against the benefits.  It's currently not clear
to me what the benefits actually are, to anyone other than automake
maintainers.

Currently, the benefits to automake maintainers is clear, there may be
some benefit to package maintainers (hopefully by making automake easier
to use), and there seems to be no benefit to users at all.


The benefits of depending on GNU make have yet to be enumerated.  It 
would behoove the proponents this change to do so.


Some benefits (somewhat) noticeable by end users that I see are:

  o Packaged Makefile.in (or GNUmakefile.in) can be smaller since GNU
make string functions and other enhanced functionality can be used to
eliminate/reduce Makefile code currently generated via Automake
perl code.  Perhaps the GNUmakefile.in could be 1/3rd or even 1/4
the size Makefile.in is today.

  o Full header dependencies do not need to be (as) optional.

  o Some functionality delivered as scripts (e.g. 'compile') could be
subsumed by the Makefile so builds might be slightly faster.

  o Libtool script functionality could be assimilated into the
Makefile so builds may be somewhat faster.

These are all marginal improvements from an end-user's perspective.

However, a good argument can be made that the GNU build tool should 
accept Makefile.am files directly, eliminating packaged Makefile.in 
files.  This is yet another argument that Automake should not depend 
on classic 'make' or even current GNU make.  There is no reason to 
deliver pre-processed template files to the user if GNU is free to 
insist that the user install a GNU build tool in advance (which it 
never has before).  If GNU is going to insist that the user install 
its own tool in advance, then it seems like that tool should provide 
quite a lot more functionality than other similar tools the user 
already has available.


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

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefano Lattarini]

On Tuesday 22 November 2011, Nick Bowler wrote:
> On 2011-11-22 17:46 +0100, Stefano Lattarini wrote:
>
> [MEGA-SNIP]
>
> > See also:
> >   
>
> Yes, it is sad that many package maintainers fail to properly test their
> build systems.
>
Consider that some maintainers cannot; not everyone can afford to have
access to all the *BSD, as well as Solaris, AIX, Windows (for Cygwin) ...

> By the same argument, "GNU-make-requiring automake" is
> never going to really support GNU make versions older then 3.82 because
> maintainers won't bother to test with older versions.
>
While you raise a partly valid point, consider that installing older
versions of GNU make is pretty easy.  Not so with other makes
implementation (with some exceptions; for example, FreeBSD make
is packaged for Debian).

> Regardless, I don't think this is a good reason to force non-portability
> on those who take the time to test other make implementations.
>
I don't plan to "force" this on them out of the blue.  As I've said,
automake 1.x is here to stay for various years at least (and more if
automake2 / automire doesn't take off).

> > > But when a user building a free software package for the first time in
> > > their life runs "./configure && make", and receives a spew of cryptic
> > > messages about syntax errors or worse, I suspect that their first
> > > reaction is not going to be "Whoops!  I should have run gmake instead."
> > > More likely it will involve much more colourful language, and they will
> > > be left with a bitter impression.
> >
> > OK.  So let's design the new automake to prevent this :-)  My above
> > proposal of "automatic re-execution with GNU make" might help here.
> > WDYT?
> 
> It's certainly an option.  If we go this route, I think we need, at the
> very least:
> 
>  * Autoconf tests to find a working GNU make.
>
Agreed.  That should be pretty easy BTW, and could be crammed into
AM_INIT_AUTOMAKE

>  * Put GNU make logic in GNUmakefile, so that other makes do not try to
>parse it, and GNU make users don't have to care.
>
+1

>  * Put stubs in the Makefile for all common targets that will then
>re-invoke GNU make.
+1

>  * Allow package maintainers to easily define new stubs for their custom
>targets
+1

>(bonus points: make this automatic).
>
+0.5 ("if it doesn't turn out to be too difficult")

>
> [SNIP]
>

Regards,
  Stefano

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Nick Bowler]

On 2011-11-22 17:46 +0100, Stefano Lattarini wrote:
> On Tuesday 22 November 2011, Nick Bowler wrote:
> > This especially includes users who
> > have no idea that there's a difference between GNU make and the version
> > of "make" that is already on their system.
>
> Honestly, there are such users today?  I mean, almost every Unix newbie
> these days either:
> 
>  - installs a Linux distro, which comes with GNU make as the default 
>make program (and we're also ignoring the fact that most such
>users will install stuff only through the distro's package manager
>anyway, not from sources -- and I don't blame them for this!);
>  - is using Mac OS X, which comes with GNU make as the default make;
>  - installs Cygwin (or possibly MinGW/MSYS) or on his Windows system,
>thus getting GNU make as the default make in the process.
> 
> I expect a user of the *BSD systems (and even more of proprietay Unixes)
> will be learned enough to know the difference between the vendor make and
> GNU make.

This is probably true if the user installed such a system on their own
PC.  But people use computing systems that they did not install
themselves, especially with shared systems at schools.  At my alma
mater, the main computing environment was Solaris (thus "make" was
Solaris make rather than GNU make).  For many undergrads, this represents
their first encounter with unix-like systems.  We should strive to make
their experiences with free software on those systems a good one!

> That said, having some layer that would allow common "make TARGET" commands
> to re-invoke themselves with GNU make (maybe with a proper warnings) would
> be worthwhile; but this would *not* be done for the benefit of the newbies,
> rather to help out the experienced-but-distracted(-or-lazy) user.
> 
> > This is, I think, the single best way to encourage users to become more
> > involved in the free software community.  If the user can't easily build
> > a package, they won't test new versions and they won't test patches.
>
> Seriously, a user experienced enough to try out a patch will not
> have a problem understanding the difference the vendor make and
> GNU make, and to act consequently.

Maybe so.  On the other hand, if you search the web, today, you can
easily find instructions on how to apply patches.  About as easily as
you will find instructions saying to build a package using
"./configure && make".

Regardless, testing new versions is orthogonal.  If the user gives up
after failing to build from a release tarball they'll never even get to
testing patches.

> > (It's truly unfortunate that many popular GNU/Linux distros deliberately
> > make this more difficult than it needs to be, but I digress).
> > 
> > I have no doubt that using GNU make will make the the automake
> > maintainers' jobs easier.  It might even make the jobs of individual
> > package maintainers easier.
>
> See also:
>   

Yes, it is sad that many package maintainers fail to properly test their
build systems.  By the same argument, "GNU-make-requiring automake" is
never going to really support GNU make versions older then 3.82 because
maintainers won't bother to test with older versions.  Regardless, I
don't think this is a good reason to force non-portability on those who
take the time to test other make implementations.

> > But when a user building a free software package for the first time in
> > their life runs "./configure && make", and receives a spew of cryptic
> > messages about syntax errors or worse, I suspect that their first
> > reaction is not going to be "Whoops!  I should have run gmake instead."
> > More likely it will involve much more colourful language, and they will
> > be left with a bitter impression.
>
> OK.  So let's design the new automake to prevent this :-)  My above
> proposal of "automatic re-execution with GNU make" might help here.
> WDYT?

It's certainly an option.  If we go this route, I think we need, at the
very least:

 * Autoconf tests to find a working GNU make.
 * Put GNU make logic in GNUmakefile, so that other makes do not try to
   parse it, and GNU make users don't have to care.
 * Put stubs in the Makefile for all common targets that will then
   re-invoke GNU make.
 * Allow package maintainers to easily define new stubs for their custom
   targets (bonus points: make this automatic).

> > Now, I'm not fundamentally opposed to the idea, but it has to be done
> > _right_.
> >
> Well, yes.  And I certainly value the issues you've raised (even if
> they are in no way show-stoppers IMHO).

We must weigh the costs against the benefits.  It's currently not clear
to me what the benefits actually are, to anyone other than automake
maintainers.

Currently, the benefits to automake maintainers is clear, there may be
some benefit to package maintainers (hopefully by making automake easier
to use), and there seems to be no benefit to users at all.

On the other h

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefano Lattarini]

On Tuesday 22 November 2011, Nick Bowler wrote:
> Hi Stefano,
>
Hello Nick.

> On 2011-11-21 21:56 +0100, Stefano Lattarini wrote:
> > > > Notice that, despite of the (semi)-consensus reached there, I'm becoming
> > > > more and more convinced that, in the long run, requiring GNU make to run
> > > > the automake-generated Makefiles would be an acceptable move (for 
> > > > automake
> > > > 2.0, that is).  But only because GNU make is *so* much better than
> > > > portable make (which is extremely limited), because GNU make is very
> > > > portable and easy to build and install (and free from bootstrapping
> > > > problems AFAIK), and because the incompatibilities between different
> > > > make versions are so appalling.
> 
> I think this discussion is for the most part ignoring what is (IMO) the
> most important issue: it must be easy for ordinary (non-developer) users
> to build free software packages!
>
Yes, and that's why I'm suggesting to start requiring only GNU make, and
not also bash (which would undoubtedly make it easier to write Makefile
recipes) and GCC 4.x or later (which would make the automatic dependency
tracking so much easier), and GNU awk ... OK, you've got the gist I think.

> This especially includes users who
> have no idea that there's a difference between GNU make and the version
> of "make" that is already on their system.
>
Honestly, there are such users today?  I mean, almost every Unix newbie
these days either:

 - installs a Linux distro, which comes with GNU make as the default 
   make program (and we're also ignoring the fact that most such
   users will install stuff only through the distro's package manager
   anyway, not from sources -- and I don't blame them for this!);
 - is using Mac OS X, which comes with GNU make as the default make;
 - installs Cygwin (or possibly MinGW/MSYS) or on his Windows system,
   thus getting GNU make as the default make in the process.

I expect a user of the *BSD systems (and even more of proprietay Unixes)
will be learned enough to know the difference between the vendor make and
GNU make.

That said, having some layer that would allow common "make TARGET" commands
to re-invoke themselves with GNU make (maybe with a proper warnings) would
be worthwhile; but this would *not* be done for the benefit of the newbies,
rather to help out the experienced-but-distracted(-or-lazy) user.

> This is, I think, the single best way to encourage users to become more
> involved in the free software community.  If the user can't easily build
> a package, they won't test new versions and they won't test patches.
>
Seriously, a user experienced enough to try out a patch will not
have a problem understanding the difference the vendor make and
GNU make, and to act consequently.

> (It's truly unfortunate that many popular GNU/Linux distros deliberately
> make this more difficult than it needs to be, but I digress).
> 
> I have no doubt that using GNU make will make the the automake
> maintainers' jobs easier.  It might even make the jobs of individual
> package maintainers easier.
>
See also:
  

> But when a user building a free software package for the first time in
> their life runs "./configure && make", and receives a spew of cryptic
> messages about syntax errors or worse, I suspect that their first
> reaction is not going to be "Whoops!  I should have run gmake instead."
> More likely it will involve much more colourful language, and they will
> be left with a bitter impression.
>
OK.  So let's design the new automake to prevent this :-)  My above
proposal of "automatic re-execution with GNU make" might help here.
WDYT?

> Now, I'm not fundamentally opposed to the idea, but it has to be done
> _right_.
>
Well, yes.  And I certainly value the issues you've raised (even if
they are in no way show-stoppers IMHO).

Thanks,
  Stefano

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Nick Bowler]

Hi Stefano,

On 2011-11-21 21:56 +0100, Stefano Lattarini wrote:
> > > Notice that, despite of the (semi)-consensus reached there, I'm becoming
> > > more and more convinced that, in the long run, requiring GNU make to run
> > > the automake-generated Makefiles would be an acceptable move (for automake
> > > 2.0, that is).  But only because GNU make is *so* much better than
> > > portable make (which is extremely limited), because GNU make is very
> > > portable and easy to build and install (and free from bootstrapping
> > > problems AFAIK), and because the incompatibilities between different
> > > make versions are so appalling.

I think this discussion is for the most part ignoring what is (IMO) the
most important issue: it must be easy for ordinary (non-developer) users
to build free software packages!  This especially includes users who
have no idea that there's a difference between GNU make and the version
of "make" that is already on their system.

This is, I think, the single best way to encourage users to become more
involved in the free software community.  If the user can't easily build
a package, they won't test new versions and they won't test patches.
(It's truly unfortunate that many popular GNU/Linux distros deliberately
make this more difficult than it needs to be, but I digress).

I have no doubt that using GNU make will make the the automake
maintainers' jobs easier.  It might even make the jobs of individual
package maintainers easier.

But when a user building a free software package for the first time in
their life runs "./configure && make", and receives a spew of cryptic
messages about syntax errors or worse, I suspect that their first
reaction is not going to be "Whoops!  I should have run gmake instead."
More likely it will involve much more colourful language, and they will
be left with a bitter impression.

Now, I'm not fundamentally opposed to the idea, but it has to be done
_right_.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefano Lattarini]

On Tuesday 22 November 2011, Richard Stallman wrote:
>   1. We start requiring GNU make in an "experimental" automake 2.0
>development line (which might, and will, break whathever
>backward-compatibility gets in its way).
> 
> If we want to experiment with this, we should not do so in Automake!
> 
> Rather, one GNU package could drop support for ordinary Make, and see
> how users react.  If the level of complaint is not too high, then
> another GNU package could do this.
>
I like this approach.  Still, we could be even more conservative, and
have one or few GNU packages offer distribution tarballs built with
"new automake" by default, while continuing (for a while at least) to
also offer distribution tarballs built with "traditional automake".
Ideally, the download links for such "compatibility tarballs" would
not be accessible from the package's web pages directly, but only
referenced in the INSTALL file of the "new-style tarballs".

> Once many GNU packages have done
> this, we might conclude it is ok for all GNU packages to do so
> (perhaps with a few exceptions).
> 
> Then we could deprecate use of Automake to make ordinary makefiles.
> Later we could remove that support from Automake.
> 
> This is a slow, cautious process -- the way it should be.
>
I fully agree.  Being too hasty in this process would probably be the
easier way towards an assured failure.

> > Maybe in the discussion we should distinguish GNU-like systems
> > (perhaps including Mac OS)
> >
> Do you mean POSIX-like systems?
> 
> I mean GNU-like.  GNU is our main target, but if another system is
> similar enough to GNU, support for it is not much extra work.
>
OK.  So, for example, the FreeBSD and NetBSD systems could be
considered GNU-like enough, since they use gcc and g++ as the
default compiler, and comes with easily installable pre-packaged
versions of the core GNU software (make, sed, bash, and coreutils,
to name a few).

Regards,
  Stefano

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Stefano Lattarini]

Hi Paul, and thanks for the reply.  I really appreciate having the
partecipation of the GNU make maintainer in this discussion :-)

On Monday 21 November 2011, Paul Smith wrote:
> On Mon, 2011-11-21 at 21:56 +0100, Stefano Lattarini wrote:
> >   1. We start requiring GNU make in an "experimental" automake 2.0
> >  development line (which might, and will, break whathever
> >  backward-compatibility gets in its way).
> 
> If you go this route, then it's critical that the "minimal set" of
> capabilities used by this new automake be clearly documented.
>
Absolutely.  And I think the very clear and complete NEWS file in the
GNU make distribution will be of great help in this.

As of now, my opinion is that we'd want to require at least the presence
target-specific variables, of user-defined functions, of the $(eval)
builtin and of the special $(.VARIABLES) variable.  Which, if I'm not
mistaken, means we will have to require at least version 3.80 or later.

> Even something like "all features available as of GNU make 3.76" or
> whatever would be very helpful, although I would prefer an explicit
> list of capabilities.
>
Having an explicit list of required capabilities *and bugfixes* would
probaly be a good idea, esp. to play nice with patched versions of
GNU make (which might have bugfixes backported from later versions).

> There ARE multiple versions of GNU make out there and many distributions
> still ship versions many years old... I regularly get questions on the
> GNU make help lists from users referring to our web manual, which
> obviously documents the latest released version of GNU make, and they
> are confused because their version of GNU make (released in 2006 or
> whatever) does not support some of the documented features.
>

Thanks,
  Stefano

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Paul Smith]

On Mon, 2011-11-21 at 21:56 +0100, Stefano Lattarini wrote:
>   1. We start requiring GNU make in an "experimental" automake 2.0
>  development line (which might, and will, break whathever
>  backward-compatibility gets in its way).

If you go this route, then it's critical that the "minimal set" of
capabilities used by this new automake be clearly documented.  Even
something like "all features available as of GNU make 3.76" or whatever
would be very helpful, although I would prefer an explicit list of
capabilities.

There ARE multiple versions of GNU make out there and many distributions
still ship versions many years old... I regularly get questions on the
GNU make help lists from users referring to our web manual, which
obviously documents the latest released version of GNU make, and they
are confused because their version of GNU make (released in 2006 or
whatever) does not support some of the documented features.