Re: [Automake-NG] Automake-NG APIs and backward-compatibility (was: Re: [PATCH 2/2] [ng] vartypos: update news file)

[Akim Demaille]

Le 7 juin 2012 à 12:44, Stefano Lattarini a écrit :

>>> at least when it is (like in this case) easy and
>>> natural to do so.  Moreover, as I wrote in the commit message of the
>>> first patch:
>>> 
>>>   Such a whitelisting capability is a good idea even regardless this
>>>   motivation, since it helps enforcing the Autotools- philosophy
>>>   "the user is always right" (as long as he is explicit enough).
>>> 
>>> Don't you agree with my rationales?
>> 
>> I'm not sure I do actually.  Yes, I do use WERROR_CPPFLAGS and
>> such variable names, so I would have to fix some of my variables
>> if this were to be enforced.
>> 
> Still, some other people might be annoyed by the forced code churn
> though; and why not offer them an easy way out, since it very easy
> for us to do so?  Automake-NG is just starting its business, so it
> needs to keep its clients as happy as it can, at least until its
> "brand" is established.

So I'm eager to see Automake-ng-ng :)

>> Yet, much of the value of Automake comes from its strong
>> reliance on purpose conventions, especially naming conventions.
>> So, imvho, allowing exceptions in these conventions is actually
>> making Automake statements harder to read.  They become dependent
>> on the context.
>> 
> That is true, but it's a consideration that should be aimed at the
> Makefile.am writers rather than to us: "give the user enough rope"
> etc. etc.

to hang herself?

>> Instead of a declaration statement (so dependency on the
>> context), I would prefer to see another naming convention be used.
>> 
>> Actually, it's almost a pity that _ was used,
>> 
> I guess that hasn't been really a choice, but something required to
> be portable to "POSIX make".  Sigh.

Yes, of course, but I was also referring to the fact that Automake-ng
is not departing from this.

>> we could have requested
>> 
>>      bin_PROGRAMS = mv
>>      mv/CPPFLAGS = -DFOO
>> 
>> or
>> 
>>      mv.CPPFLAGS = -DFOO
>> 
>> and keep _ for copy_CPPFLAGS.  (I find the affiliation more
>> explicit with . or / than with _.)
>> 
> I absolutely agree.  But until after the first Automake-NG release is
> out, I want to keep our APIs as much similar to the ones of mainline
> Automake as possible, to facilitate transition.  Once the users have
> started to appreciate the advantages of GNU make harnessing and cleaner
> APIs, we can release an Automake-NG 2.0 with cleaner and non backward
> compatible APIs (Quagmire might be of great inspiration for this).

Why not.

> And speaking of cleaner APIs, we should truly get rid of the
> "canonicalization" of program and libraries name; for example,
> instead of this:
> 
>   bin_PROGRAMS = git-helper
>   lib_LIBRARIES = sub/libfoo.a
>   git_helper_LDADD = -lgit
>   sub_libfoo_a_SOURCES = sub/1.c sub/2.c
> 
> we might have something like this:
> 
>   bin_PROGRAMS = git-helper
>   lib_LIBRARIES = sub/libfoo.a
>   git-helper.LDADD = -lgit
>   sub/libfoo.a.SOURCES = sub/1.c sub/2.c

Very true, excellent point.

> or even like this:
> 
>   PROGRAMS[bin] = git-helper
>   LIBRARIES[lib] = sub/libfoo.a
>   git-helper[LDADD] = -lgit
>   sub/libfoo.a[SOURCES] = sub/1.c sub/2.c
>   TEST_EXTENSIONS = .tap .sh
>   LOG_DEPENDENCIES[.sh] = tests/init-sh
>   LOG_DRIVER[.tap] = $(SHELL) build-aux/tap-driver.sh

I'm not sure I understand why [foo] instead of ".foo".  Not
"." like a file name extension, but like a member access in
C, C++, Java etc.

> which is more self-explanatory and probably easier to process in
> pure GNU make.
> 
>> Maybe the convention could be simply in the use of upper case
>> instead of lowercase?
>> 
>>      mv_CPPFLAGS = COPY_CPPFLAGS
>> 
>> ?
>> 
> I don't follow you here.  Care to rephrase?

Huge typo, I forgot $().  I meant, since (i) we want to stick
to mv_CPPFLAGS for programs, and (ii) I prefer a new naming
convention for exceptions, I propose to rely on the case of
the prefix.  COPY is full uppercase, so Automake would not
require COPY to be declared.

        mv_CPPFLAGS = $(COPY_CPPFLAGS)

(COPY_ being just the example you quoted about the coreutils).