[Got this reply as email, didn't show up yet on the Gmane NNTP interface, need to reply now as later will be too busy ... sorry if this wrecks referencing properly ... the posting I am replying to here has ID <[EMAIL PROTECTED]>]
Tom Tromey writes: Soren A <[EMAIL PROTECTED]> wrote around 14 Oct 2002 news:Xns92A790D1919A9SorenA9GMANE8BUF@;80.91.224.249: > Soren> And as for GNU make, i resent it that i cannot use the full > Soren> power of GNU make when i write Autotools-based build > Soren> configurations. > > Of course you can. Just write a Makefile.in that uses GNU make > features. Nothing requires you to use automake. > > Tom Surely, and in fact I spent the better part of the last two days doing exactly this (and the names are GNUmakefile.in and GNUmakefile). But I wasn't referring to technical limitations, I was referring to "cultural" ones. I meant that I cannot use gmake features in an Autotools-based build configuration because it violates what people think is the GNU standard or policy for portable builds. I'm being a little circumspect in my phrasing ("people think") because I cannot point to exactly where a document might exist that says this. My point was that I find it easy to do difficult things in a build configuration if I employ GNU make features and don't have to invoke Automake at all because I am accomplishing what I need to with the basic Autoconf system, combined with a well-thought-out (GNU)Makefile.in. But when I go this route some people who comprise peers giving me critique and/or comprise some of my user base, will cry that "it's not portable because it requires the user to have GNU make installed." So Autotools themselves do not enforce upon me, the package maintainer / porter, which 'make' tool I am to expect (or force me to use Automake), no. I understand that. But the "public" expectation that is attached to Autotools-based build setups has become that "GNU make won't be required". What I am saying is that this is an instance where supporting people's backwardness make package maintainance / development *much* more difficult. I can and am unilaterally "changing" the standard or policy in some of the package configurations I am producing, but in doing so I am swimming against the strong currents of convention. I am raising this issue in the context of this discussion with little expectation of immediate effect but with a long-term hope that I will have contributed to swaying enough people's ideas for the change I wish to see to eventually come to pass. If enough developers who use Autotools would just say "to heck with it, I'll just tell users they need GNU make and that's that, and I'll refuse to support those who won't use it," it would change. Regards, Soren A
