[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Automake-NG] Automake-NG APIs and backward-compatibility
From: |
Stefano Lattarini |
Subject: |
Re: [Automake-NG] Automake-NG APIs and backward-compatibility |
Date: |
Thu, 07 Jun 2012 14:22:36 +0200 |
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
- Re: [Automake-NG] [PATCH 0/7] Move detection of possible typos in _SOURCES etc. at make runtime, (continued)
- Re: [Automake-NG] [PATCH 0/7] Move detection of possible typos in _SOURCES etc. at make runtime, Akim Demaille, 2012/06/06
- [Automake-NG] Issues with the testsuite idiom ". ./defs || Exit 1" (was: Re: [PATCH 0/7] Move detection of possible typos in _SOURCES etc. at make runtime), Stefano Lattarini, 2012/06/06
- Re: [Automake-NG] [PATCH 0/7] Move detection of possible typos in _SOURCES etc. at make runtime, Stefano Lattarini, 2012/06/06
- [Automake-NG] [PATCH 1/2] [ng] vartypos: allow user to whitelist false positives, Stefano Lattarini, 2012/06/06
- [Automake-NG] [PATCH 2/2] [ng] vartypos: update news file, Stefano Lattarini, 2012/06/06
- Re: [Automake-NG] [PATCH 2/2] [ng] vartypos: update news file, Akim Demaille, 2012/06/07
- Re: [Automake-NG] [PATCH 2/2] [ng] vartypos: update news file, Stefano Lattarini, 2012/06/07
- Re: [Automake-NG] [PATCH 2/2] [ng] vartypos: update news file, Akim Demaille, 2012/06/07
- [Automake-NG] Automake-NG APIs and backward-compatibility (was: Re: [PATCH 2/2] [ng] vartypos: update news file), Stefano Lattarini, 2012/06/07
- Re: [Automake-NG] Automake-NG APIs and backward-compatibility (was: Re: [PATCH 2/2] [ng] vartypos: update news file), Akim Demaille, 2012/06/07
- Re: [Automake-NG] Automake-NG APIs and backward-compatibility,
Stefano Lattarini <=
- Re: [Automake-NG] [PATCH 2/2] [ng] vartypos: update news file, Stefano Lattarini, 2012/06/07
- Re: [Automake-NG] [PATCH 1/2] [ng] vartypos: allow user to whitelist false positives, Stefano Lattarini, 2012/06/07