* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 09:58:36PM CET: > On Wednesday 12 January 2011, Ralf Wildenhues wrote: > > The upsides are obvious. > > > If I'm not deluding myself, most of the contents of my proposal were > aimed at showing why I believe that requiring GNU make is a reasonable > and sensible policy, not to show what the advantages of such a policy > would be -- quoting myself: > > `` And the gains in terms of maintainability, testability, and > possibility of optimization are obvious. ''
Sure. You discuss the upsides of the strategy. What I was asking for is a discussion of the downsides of requiring GNU make, and arguing why they are not a problem *for our users*. *That* is what is needed to convince those who do consider requiring GNU make outright a regression. > > I was planing to introduce optional GNU make-specific code, and allowing > > to let the user specify "my project requires GNU make anyway", which > > would enable Automake to emit better code. Arguably more complex than > > requiring GNU make outright, but it wouldn't throw away all the make > > portability work that exists in Automake. > > > Hmm... so you're telling me that "This code should be kept because it > had been difficult to write it" is an acceptable rationale? ;-> No. I'm saying that that portability is a *feature*. You want to remove that feature. You need to bring solid reasons why the feature is worthless, used by nobody, and nobody is interested in it. And, of course, why we should abandon the GNU Coding Standards mandate of only requiring a small fixed set of Posix tools. This thread has already shown that to not be true, judging from a couple of the other answers. > (BTW, that portability-related work has already and definitely served > the purpose of making automake usage more widespread, so I don't think > the efforts that went into it would ever be "wasted", even if the code > they produced is going to be removed). OK, so you're acknowledging that the feature serves a useful purpose. Why should we then remove it? > > But let me rephrase the critique in a poignant way: if you want to > > require GNU make anyway, what is your rational to not use quagmire > > instead of Automake? > > > You mean this? > <http://code.google.com/p/quagmire/> Yes. Please drop ridiculing in an otherwise sensible discussion, it weakens your argumentation. (It's also not the first time we've had this discussion on this list.) Tom Tromey (who, should you not know, has done more work on Automake than anybody else), started quagmire, as a response to the idea that GNU make should be required and exploited. It is a rational answer given the following thoughts: when you require GNU make, you - want to allow your users to use GNU make to its fullest extent, - can fix the problem of non-parallel configure tests, - can avoid the slow m4+perl preprocessing steps. * Stefano Lattarini wrote on Wed, Jan 12, 2011 at 10:12:37PM CET: > On Wednesday 12 January 2011, Ralf Wildenhues wrote: > > Apart from that, if Automake requires GNU make, its users would rightly > > demand that Automake ought to understand GNU make-specific constructs. > > > In which sense exactly? If you mean in something like: > > bin_PROGRAMS = $(call my-macro,foo,bar) Well, more likely, things like foo_SOURCES = $(wildcard *.cc *.h) which are asked for every few months. We have a FAQ entry about it. > then they should resign not to have it working for quite a long > time I fear. But that's something that would make me cringe if I had to use GNU make anyway. > After all, automake is just a pre-processor, not a GNU make superset. But that mis-feature would be bug number One in this case. > I stress this because I think that the only way not to have the > hypotetical "automake2" end up as vaporware would be to start from > the current automake implementation, ensuring we don't break the > API nor regress the testsuite while we convert to gmake-only output. * Stefano Lattarini wrote on Wed, Jan 12, 2011 at 10:36:52PM CET: > The "answer" I was speaking about would have been concerned with why I think > that the quagmire *design* and *roadmap* are broken (even ignoring its "less > than excellent" developement status). Actually, I consider the design not so bad, but that's fairly irrelevant to this discussion. > Okay, at this point I can as well write that answer out summarily: > > - I want something that is backward-compatible with automake 1.11 as > much as possible (I mean 98/99% compatible), and that works from > "day 0". Otherwise it won't stand any real chance of being used > by real-worls projects. Well, there are counter examples (CMake, a couple of others) that show that it is possible. But it would be a large, not a small, effort, and it is not clear that a new contester would stand a chance now. One cannot tell without trying though. You are probably right in that many alternative build tools have not taken off because they (necessarily) lacked compatibility, including quagmire. > - I don't want to rewrite autoconf; with all its flaws, it rocks > and is incredibly mature ans well-written. FWIW, I don't think quagmire, in the first iteration, wanted to replace Autoconf at all. > - I don't want to rewrite libtool in GNU make. The very idea of > trying to do so scares the hell out of me. This is fear, not rational argumentation. > - I think that keeping configuration and build steps separated is > a very good idea. I don't see any good reason for this, by the way. I haven't yet see any argument in favor of "GNU make-only support" versus "improvements for cases where GNU make can be assumed", that would appeal to Automake users (rather than only to laziness of the Automake developers). Thanks, Ralf
