Re: Static library naming

[Peter Rosin]

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. But after having done that,
nothing is broken except for the (mostly) cosmetic naming issue.
Given that its mostly a cosmetic issue, I just assumed that the
tolerable level of "crap" in the Automake code and usage was
significantly lowered, which in turn might influence what kind of
solutions to consider. I.e. a new primary (cleanest syntax, but
maybe too "rich"?) vs. some kind of encoding of the library name
(&hello, lib(hello) or just libhello, which is best?) vs. something
else (ideas welcome of course).

Yes, I can probably beat Automake into generate hello.lib when
MS tools are in use by jumping through hoops on a project by
project basis with conditionals and (untested) stuff like the
below example .am file, but that's not very concise and unlikely
to ever get accepted into anything who has a decent maintainer.
The work is also basically endless, where a fix in Automake at
least has a chance of spreading "automatically".

if MSTOOLS
LIBHELLO = hello.lib
lib_LIBRARIES = hello.lib
hello_lib_SOURCES = $(HELLOSOURCES)
else
LIBHELLO = libhello.a
lib_LIBRARIES = libhello.a
libhello_a_SOURCES = $(HELLOSOURCES)
endif
HELLOSOURCES = foo.c bar.c

bin_PROGRAMS = hello
hello_SOURCES = hello.c
hello_LDADD = $(LIBHELLO)

It would be nice to make that (something like):

lib_LIBRARIES = lib(hello)
libhello_SOURCES = foo.c bar.c

bin_PROGRAMS = hello
hello_SOURCES = hello.c
hello_LDADD = $(am_libhello)

and lose the MSTOOLS crap from configure.ac in the process.

BTW, maybe it is sufficient to simply drop the .a part of the
library name and use that to "encode" that os/tool-dependent
naming is desired? I.e. "lib_LIBRARIES = libhello" in the above
example. Because exactly how many users have created libraries
without any filename extension at all? The "strangest" names I
have found are a bunch of "noinst_LIBRARIES = lib.a" in newlib
(that usage is also present in some other projects) but I
guess that will not translate well to any new scheme we come
up with because .lib is probably not a good name for any
library. But maybe I simply didn't look hard enough for
extensionless foo_LIBRARY = names?

Cheers,
Peter