Re: [Automake-NG] Automake-NG APIs and backward-compatibility

[Stefano Lattarini]

On 06/07/2012 01:52 PM, Akim Demaille wrote:
>
>>> 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?
>
Exactly.  After all, any amount of rope long enough to do something
useful with is usually also long enough to hang oneself, no?

>> 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
>>
Oops, here I meant:

   LDADD[git-helper] = -lgit
   SOURCES[sub/libfoo.a] = sub/1.c sub/2.c

Sorry for the confusion.

>>   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.
>
But we have to deal with file names extensions and subdirectory
components as well in our Makefiles, so the use of '.' or '/' as
"accessor" might be ambiguous and confusing.  I proposed "[]"
because it is used to access elements of python dictionaries, but
we might got for a more "perlish vibe" instead, using "{}":

    LIBRARIES{lib} = sub/libfoo.a
    SOURCES{sub/libfoo.a} = sub/1.c sub/2.c

or for a "C-like vibe", using "->":

    LIBRARIES->lib = sub/libfoo.a
    SOURCES->sub/libfoo.a = sub/1.c sub/2.c

This would also solve a lot of namespacing problems, without requiring
us to add an "AM_" prefix everywhere: "if a variable name contains
matches the '*{*}*' or '*->*' wildcards, is is reserved by Automake").

>> 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).
> 
Hmm... no, this smells of too much "automagic" and muddiness.  I'd
rather follow python Zen here:

   - Explicit is better than implicit
   - Simple is better than complex
   - Special cases aren't special enough to break the rules.
   - Although practicality beats purity.

So: process all the '_LDADD' etc. variables (simple and no special-cased),
excluded those the users tell us not to process (explicit and practical,
although not "pure").

Regards,
  Stefano