On 2012-09-24 09:54, Stefano Lattarini wrote:
> On 09/23/2012 11:47 PM, Peter Rosin wrote:
>> On 2012-09-20 16:36, Stefano Lattarini wrote:
>>> On 09/20/2012 12:49 AM, Peter Rosin wrote:
>>>> When you write
>>>>
>>>> lib_LIBRARIES = libhello.a
>>>>
>>>> you express the desire to build an "hello" archive. Virtually
>>>> everywhere such an archive is expected to be named, tada,
>>>> libhello.a
>>>>
>>>> Enter Windows. When using any and all toolchains not
[SNIP]
>> This sounds ok to me, it would require adding support to the
>> compile script for -lhello -> libhello.a, but now we know why
>> we need it and that we actually do need it. The only concern is
>> that I'm not 100% happy with requiring Automake-NG, as outlined
>> above. So, how much harder is it to support this kind of stuff
>> in vanilla Automake? What are the obstacles? It looks just like
>> variable expansion to me, and how broken can that be? Is it
>> that a construct such as $(am_lib_foo) can't be portably used
>> in every place it would need to?
>>
>> Because you are surely not suggesting that support for the
>> current
>> lib_LIBRARIES = libhello.a
>> is going away over this, are you?
>>
> Actually, I was suggesting precisely that :-/
I expect that to be a hard sell? And I see no clear way to select
non-standard library names like "hello.a".
>> (and that the reason for going to Automake-NG would be
>> this API-break)?
>>
> Exactly -- I suggested doing it only for Automake-NG since such
> a backward-incompatibility would be totally unacceptable in
> mainline Automake.
>
> But then it occurs to me: we could make my proposal perfectly
> backward-compatibly by adding a new "special syntax" like:
>
> lib_LIBRARIES = &hello
Or add a new primary
lib_PORTLIBS = hello
or
lib_ARCHIVES = hello
because the & sign is just plain ugly. Or if a new primary
is too "expensive", or if a GOOD primary name can't be found
(I'm not too fond of the above), perhaps
lib_LIBRARIES = lib(hello)
which seems very unlikely even for a non-standard library name.
But I don't really care all that much about the exact syntax.
> that will do all the translations and variable setting I proposed
> above, while continuing to support:
>
> lib_LIBRARIES = libhello.a
>
> seamlessly (but now with a warning in the 'extra-portability'
> category, starting from Automake 1.14 at least).
>
> Does this sound better?
Yes, because I don't want this to be Automake-NG only. But since
this scheme is opt-in, the compile script "must" be adjusted to
handle libhello.a anyway. And with an adjusted compile script, I
suppose the acceptable level of ugliness elsewhere is lowered, as
it only fixes the (mostly) cosmetic naming problem.
Cheers,
Peter
