On Saturday 19 November 2011, Stefano Lattarini wrote:
On Saturday 12 November 2011, Stefano Lattarini wrote:
SETUP:
Solaris 10, rich /usr/local (e.g., contains `expr' from GNU coreutils
6.9 and gawk 3.1.5), VPATH build, perl 5.10.0, autoconf 2.62, testsuite
run with GNU make 3.82,
On Sunday 23 October 2011, Stefano Lattarini wrote:
Hi Ralf.
On Thursday 20 October 2011, Stefano Lattarini wrote:
On Wednesday 19 October 2011, Ralf Wildenhues wrote:
Am I missing something?
I hope so :-) -- otherwise I've completely misunderstood something
cardinal here.
On 11/21/2011 09:56 PM, Stefano Lattarini wrote:
Here is my tentative plan to act on the proposal:
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).
2. Concurrently,
Hi Paolo, thanks for the reply.
On Tuesday 22 November 2011, Paolo Bonzini wrote:
On 11/21/2011 09:56 PM, Stefano Lattarini wrote:
Here is my tentative plan to act on the proposal:
1. We start requiring GNU make in an experimental automake 2.0
development line (which might,
On Tuesday 22 November 2011, Paolo Bonzini wrote:
On 11/22/2011 01:13 PM, Stefano Lattarini wrote:
When we introduced shell functions into Autoconf, and in general updated
Autoconf/M4sh/libtool for relatively new shells (new = newer than
Ultrix), it was successful exactly because no
At the risk of repeating myself from the last time this question came
up, let me selfishly say as a NTP maintainer that I do not look
forward to NTP configure failing with a message indicating GNU make is
required and could not be located. I have no appreciation for how
much simpler and easier to
On 11/22/2011 04:35 PM, Stefano Lattarini wrote:
1. Automake 2 turns out to be a failure, it gets abandoned, and
Automake 1 becomes again the center of all our developement
efforts. No problem for you, since you're still using this older
automake.
2. Automake 2 is a success,
On Tuesday 22 November 2011, Paolo Bonzini wrote:
On 11/22/2011 04:35 PM, Stefano Lattarini wrote:
1. Automake 2 turns out to be a failure, it gets abandoned, and
Automake 1 becomes again the center of all our developement
efforts. No problem for you, since you're still using
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
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
Hi Stefano,
Stefano Lattarini stefano.lattar...@gmail.com skribis:
Here is my tentative plan to act on the proposal:
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).
On Tuesday 22 November 2011, Ludovic Courtès wrote:
Hi Stefano,
Hi Ludo.
Stefano Lattarini stefano.lattar...@gmail.com skribis:
Here is my tentative plan to act on the proposal:
1. We start requiring GNU make in an experimental automake 2.0
development line (which might, and
Hi Ralf.
On Tuesday 22 November 2011, Ralf Corsepius wrote:
On 11/22/2011 04:50 PM, Bob Friesenhahn wrote:
On Tue, 22 Nov 2011, Stefano Lattarini wrote:
Which IMHO would be a killer benefit :-)
But now that I think about it, a GNU make-based rewrite might also offer
better
On Tue, 22 Nov 2011, Ralf Corsepius wrote:
Another question is if GNU make is really good enough to warrant this
sort of change.
Good point - gmake has a long history of hickups :-)
My question was not meant to imply that GNU make is riddled with bugs.
My question is if deciding to move to
On Tuesday 22 November 2011, Ralf Corsepius wrote:
That said, apart from the fact that each generation of automake
maintainers at one point in his automake-carriere comes up with switch
to gmake,
This to me is the real point. I feel history repeats.
I guess that's the sad fate of humanity
Hi Bob.
On Tuesday 22 November 2011, Bob Friesenhahn wrote:
On Tue, 22 Nov 2011, Ralf Corsepius wrote:
Another question is if GNU make is really good enough to warrant this
sort of change.
Good point - gmake has a long history of hickups :-)
My question was not meant to imply that GNU
On Tue, 22 Nov 2011, Stefano Lattarini wrote:
Or simpler: So far, automake has not been using gmake, so why should it
now start doing so?
Because IMHO the cost/benefit ratio of using portable make only has become
higher and higer -- not because the cost of writing portable Makefiles has
On Tue, 22 Nov 2011, Ralf Corsepius wrote:
Build dependencies and knowledge of the current build state are not
adequately handled by timestamp-based 'make', even if it is GNU make.
I do not agree with this claim - More precisely, I think, timestamp based
handling is the only viable
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
On Tuesday 22 November 2011, Nick Bowler wrote:
On 2011-11-22 17:46 +0100, Stefano Lattarini wrote:
[MEGA-SNIP]
See also:
http://lists.gnu.org/archive/html/automake/2011-01/msg00091.html
Yes, it is sad that many package maintainers fail to properly test their
build systems.
Consider
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
[adding automake-patches]
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10111
On Tuesday 22 November 2011, Stefano Lattarini wrote:
Attached are two test scripts that expose the bug for the related but
slightly different cases of an `.m4' file included by `configure.ac'
and an
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
I've been wondering, why not 'merge' the generator and the executor
and consider the file format an implementation detail?
Olaf
On 11/22/2011 04:50 PM, Bob Friesenhahn wrote:
On Tue, 22 Nov 2011, Stefano Lattarini wrote:
Which IMHO would be a killer benefit :-)
But now that I think about it, a GNU make-based rewrite might also offer
better extensibility (if we get the APIs right, that is), and that would
be a *great*
On 22 November 2011 15:50, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote:
It would be useful to enumerate the user-visible benefits if Automake can
depend on using GNU make. Otherwise it is difficult to do a cost/benefit
analysis from the user perspective. Can you and others please
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
On 11/22/2011 06:04 PM, Stefano Lattarini wrote:
Hi Ralf.
On Tuesday 22 November 2011, Ralf Corsepius wrote:
On 11/22/2011 04:50 PM, Bob Friesenhahn wrote:
On Tue, 22 Nov 2011, Stefano Lattarini wrote:
Which IMHO would be a killer benefit :-)
But now that I think about it, a GNU make-based
On 11/22/2011 06:47 PM, Bob Friesenhahn wrote:
On Tue, 22 Nov 2011, Ralf Corsepius wrote:
Another question is if GNU make is really good enough to warrant this
sort of change.
Good point - gmake has a long history of hickups :-)
My question was not meant to imply that GNU make is riddled
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)
[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
On 22 November 2011 20:48, Bob Friesenhahn bfrie...@simple.dallas.tx.us 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
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
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
I probably still do the lion's share of updates to the Makefile.am's in
NTP, at least for nontrivial changes. But I'm not sure that matters for
this discussion. (And Dave Hart has done a few of the tricky ones,
too.)
NTP started using autoconf as its detection needs are ... nontrivial,
and
Ralf wrote:
If automake so far has been able to achieve its job, by not using
gmake proprietary constructs in its Makefile.ins, then there should
not be any need for automake to _now_ start using gmake-constructs in
Makefile.ins.
I agree, there is probably no *need*.
Or simpler: So far,
unsubscribe
On 11/22/2011 8:50 AM, Bob Friesenhahn wrote:
It would be useful to enumerate the user-visible benefits if Automake
can depend on using GNU make.
- For me, the biggest potential benefit isn't to Automake, but to
Autoconf: if it were reimplemented in terms of GNU make, you'd then get
On 11/22/2011 10:33 AM, Ralf Corsepius wrote:
So far, automake has not been using gmake, so why should it
now start doing so?
Because gmake is all but ubiquitous, and has been so for a decade.
The only exception I can think of is the BSDs, which still stubbornly
stick to BSD make,
Warren wrote:
So far, automake has not been using gmake, so why should it
now start doing so?
Because gmake is all but ubiquitous, and has been so for a decade.
The only exception I can think of is the BSDs, which still stubbornly
stick to BSD make, apparently for political reasons. I
On 11/22/2011 11:18 AM, Ralf Corsepius wrote:
is gmake stable enough or is gmake just another moving target
just like many other GNU-programs?
If you go back just three versions, you've gone back in time ~9 years.
That is about the length of time that GNU make has been the default
On Tue, Nov 22, 2011 at 16:46, Stefano Lattarini
stefano.lattar...@gmail.com 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
On 11/22/2011 9:18 AM, Nick Bowler wrote:
users who
have no idea that there's a difference between GNU make and the version
of make that is already on their system.
That's not the user's job today, and there's no reason it would have to
be in this new world, either. Autoconf's raison
On Tue, 22 Nov 2011, Warren Young wrote:
Besides, why should BSD purity get to hold back the Autotools? If the
distrowatch.com stats are to be believed, *BSD's market share is under 1%
that of Linux, which itself is only about 1% of the overall market of
machines the Autotools can
On 11/22/2011 7:46 PM, Bob Friesenhahn wrote:
P.S. I choose to be a 1 percenter.
1% I'm fine with. It's 0.001% I'm talking about.
Do we let OpenVMS drive Autotools' direction, too? OS/2? BeOS?
Ooops, nope. GNU make probably shipped on those platforms, too. :)
Warren wrote:
On 11/22/2011 6:02 PM, Harlan Stenn wrote:
The BSDs have their good reasons to want to avoid GPL'd code, especially
GPL3.
Besides, why should BSD purity get to hold back the Autotools?
So GNU/Linux purity is fine but BSD purity is not?
If the distrowatch.com stats are to
On Tue, 2011-11-22 at 19:50 -0700, Warren Young wrote:
On 11/22/2011 7:46 PM, Bob Friesenhahn wrote:
P.S. I choose to be a 1 percenter.
Do we let OpenVMS drive Autotools' direction, too? OS/2? BeOS?
Ooops, nope. GNU make probably shipped on those platforms, too. :)
As a matter of fact
On Tue, 2011-11-22 at 18:33 +0100, Ralf Corsepius wrote:
But I recall there had been massively broken gmake
releases and releases with major functional changes, which had broken
a lot.
I don't believe that this is so. There have been changes which broke
some makefiles here and there, and
48 matches
Mail list logo
