Re: [CRAZY PROPOSAL] Automake should support only GNU make

[Юрий Пухальский]

Good day.

I'll throw my humble userish $0.02 in here.

First of all, i like the idea of autotools working in any POSIX
enviroment, requiring a set of tools that is everywhere by definition.
Because when for example i try to compile my project in hostile
environment with suspicious admins that watch every my step -
requiring GNU make would be a hindrance. There are very many
*seriously* old systems out there, at least here, in poor Russia.

Also, if we step away from requiring only a standard set of tools,
that makes a precedent. Next step would easily be to require bash
(which, by the way, i believe to be much more ubiquitous that
gnu/bsd-make). That will surely clarify the utilities' code, if we
drop the support of them old shells. So the same reasoning will apply
to this also. So the trend, i'm afraid, will be like this - stick to
GNU software. I have nothing against it, but that is a thing to
consider - a balance between developers' lazyness and users' comfort.
(I already don't like that the autotools' set requires gnu M4).

2011/1/13 Stefano Lattarini <address@hidden>:
> On Wednesday 12 January 2011, Ralf Wildenhues wrote:
>> > * Stefano Lattarini wrote on Wed, Jan 12, 2011 at 07:01:47PM CET:
>> >
>> > > And more than this -- brace yourself -- I'm starting to think that
>> > > automake should *really* start supporting *only* GNU make (at least
>> > > from version 3.75 or so).
>> >
>> > If you want support for this, then you need to discuss away the
>> > downsides (i.e., convince those _opposed_ to the idea, not the
>> > rest).  The upsides are obvious.
>>
>> 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)
>
> then they should resign not to have it working for quite a long
> time I fear.
>
> After all, automake is just a pre-processor, not a GNU make superset.
>
> 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.
>
>> I don't consider that a feasible endeavor, short of reimplementing
>> GNU make inside Automake.
>>
>
> Regards,
>   Stefano
>



-- 
«The good thing about standards is there are so many to choose from.»