Re: Static library naming

[Peter Rosin]

On 2012-10-02 16:37, Stefano Lattarini wrote:
> Hi Peter, sorry again for the delay.
> 
> On 09/26/2012 10:40 AM, Peter Rosin wrote:
>> On 2012-09-25 21:33, Stefano Lattarini wrote:
>>> [Dropping Automake-NG list, from the next reply]
>>>
>>> On 09/24/2012 10:51 AM, Peter Rosin wrote:
>>>>
>>>> [MEGA-SNIP]
>>>>
>>>> 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.
>>>>
>>> So, if I understand correctly, you're saying that at this point it's
>>> better and simpler to just adjust the 'compile' script?  Or am I
>>> misunderstanding? (in which case, sorry to be so dense!)
>>
>> Short answer: No, not quite, I still would like the possibility to
>> have Automake generate hello.lib without jumping through hoops.
>> Sorry for not being clear enough.
>>
>> Long answer: I attempted to say that given the plan to require
>> projects to opt-in for hello.lib instead of hardcoding libhello.a,
>> the compile script has to accommodate those that don't opt-in and
>> thus also support the libhello.a naming.
>>
> OK, clearer now.  This first step ("support the libhello.a name for
> those who don't opt-in") could also be done for Automake 1.12.5,
> if anyone is kind enough to provide a patch :-)

Attached (form maint).

> IMHO we should want to be clearer that something "magic" is
> going on.  So something like "lib(hello)" would still be better.
> (Determining the final colour of the bikeshed is left as
> exercise to the user ;-)

The one with the brush gets to decide, as usual. :-)

Cheers,
Peter

0001-compile-support-libfoo.a-naming-when-wrapping-Micros.patch
Description: Text Data