Re: proposal to fork the build-tools projects

[Soren A]

[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 
<address@hidden>]

Tom Tromey writes:

Soren A <address@hidden> wrote 
around 14 Oct 2002 news:address@hidden:
> 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