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).
