Dave Hart davehart_gmail_exchange_...@davehart.net writes:
If anyone knows of examples of
non-recursive Makefile implementations that manage to preserve the
recursive make property of being able to make in a subdir to make a
subset, please share so we can learn from their pioneering.
Could
I agree the reason becomes less compelling as more capable systems
become more commonplace, but I do not agree ancient RISC boxes are no
longer an interesting target for current NTP builds.
The machine I use (and many of us, too) has a MIPS-like chip, the
Loongson.
--
Dr Richard
On 11/24/2011 04:51 PM, Richard Stallman wrote:
I agree the reason becomes less compelling as more capable systems
become more commonplace, but I do not agree ancient RISC boxes are no
longer an interesting target for current NTP builds.
The machine I use (and many of us, too)
On 11/22/2011 8:03 PM, Dave Hart wrote:
If Autotools are primarily intended to support those using GNU/Linux
systems and portability is not a goal, your argument that GNU has won
and BSD compatibility of free software is no longer worthwhile makes
sense.
Where did I say automake 2 =
On 2011-11-22 17:38 -0700, Warren Young wrote:
- Reduced build overhead. GNU make can do many things internally that
standard make(1) needs to shell out to do. For example, given a list of
*.cpp names, generate *.o:
OBJECTS=$(SOURCES:.cpp=.o)
You might think this is a bad example
On Wed, 23 Nov 2011, Warren Young wrote:
Yes, and we've bought that last 0.001% of compatibility with bigger, slower,
and harder to read generated Makefiles and configure scripts. TANSTAAFL. If
the price to lose some bloat, gain some speed, and increase the clarity of
these files is that I
On Wed, Nov 23, 2011 at 14:39, Warren Young war...@etr-usa.com wrote:
Yes, and we've bought that last 0.001% of compatibility with bigger, slower,
and harder to read generated Makefiles and configure scripts. TANSTAAFL. If
the price to lose some bloat, gain some speed, and increase the clarity
On Wed, 23 Nov 2011, Dave Hart wrote:
In other words, Harlan has indicated to me a non-recursive Makefile
sounds good in eliminating build system bugs due to each directory's
Makefile having a limited view of the whole, and I agree, but he
doesn't like the idea of giving up the ability to make
On 11/22/2011 8:06 PM, Harlan Stenn wrote:
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
On 11/23/2011 8:08 AM, Bob Friesenhahn wrote:
Beyond that, it mostly comes down to this simple question: What do I
type in order to invoke GNU make on this system?
No, that's easily wrapped. Aautoconf can write out both a GNUmakefile
and a Makefile.
When both are present, GNU make will
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 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 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
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
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,
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, 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
37 matches
Mail list logo
