Static library naming

[Peter Rosin]

Hi!

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
originating from GNU, such an archive is expected to be named
hello.lib instead.  Anyway, at least this is the case for
Microsoft tools and I think the other major players follows
MS on this.

Sure, it still works to have libraries named libhello.a with
MS tools (since the linker assumes that files with unknown
extensions are object files, and archives happen to fit), but
it *feels* wrong and non-native. Besides, Libtool creates
hello.lib and hello-0.dll when it builds Libtool libraries
using MS tools. Automake ought to also follow the naming
convention of the platform.

So, since nothing is impossible, the question is how
impossible it would be to beat Automake into creating
hello.lib from the above rule?

Then there's the problem with other mentions of libhello.a,
such as in build rules and dependencies for other libraries.

The only way I can see this working is to create something
like @libhello_a@ in Makefile.in for all mentions of
libhello.a in Makefile.am, and then have configure replace
that with libhello.a or hello.lib when it creates the final
Makefile.

But that will probably crash and burn when conditionals
and variables etc are entered into the mix...

Thoughts?

Cheers,
Peter