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

[Stefano Lattarini]

On 06/07/2012 12:14 PM, Akim Demaille wrote:
> 
> Le 7 juin 2012 à 12:01, Stefano Lattarini a écrit :
> 
>>> I understand why this is nice looking (to use copy_LDADD), but
>>> really, wouldn't it be saner to just some other name?  Say
>>> copy_ldadd.
>>>
>> Probably yes, but coreutils is actually using $(copy_LDADD) today, and
>> I'd like to avoid forcing too much code churn on our client packages
>> whenever possible,
> 
> Frankly, this is a non-issue.  Jim writes Perl substitution patterns
> the morning when he wakes up, just to warm up.
>
:-D

But on a more serious note, Jim is not writing the coreutils "fork"
that uses Automake-NG, I am, and when I finally present it for inclusion
in the coreutils official repository, I'd like to have as little code
churn as possible, to ease review and integration.  Then Jim will be
able to clean it up as he please -- but he will do so because he wants
to, not because he's forced to; an important difference if you ask me.

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

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

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

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

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

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

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?

> Unless you are ready for mv.CPPFLAGS :)  I am.
> 
I will... but not today, sorry (see rationale above).

Thanks for all the feeback,
  Stefano