Den 2010-09-23 20:59 skrev Ralf Wildenhues: > Hi Peter, > > * Peter Rosin wrote on Thu, Sep 23, 2010 at 10:01:16AM CEST: >> I have been wondering when I was going to run into this problem, > > Me too.
:-) >> and >> now it has happened (in the Libtool testsuite, tests/demo-deplibs.test). > >> Automake has rules for creating static libraries like so (taken from >> that test case): >> >> EXTRA_LIBRARIES = libhell0.a >> libhell0_a_SOURCES = >> libhell0_a_LIBADD = hello.$(OBJEXT) foo.$(OBJEXT) > [...] > >> Would it be possible for Automake to create static libraries of the >> hell0.lib form, when it sees "*_LIBRARIES = libhell0.a"? > > Yes, I think that should be possible in principle. At least as long as > all possible libraries to be built are known at automake run time. > (This means, that if there are any @substitutions@ in *_LIBRARIES > variables, as for example in tests/condlib.test tests/subst3.test > tests/substtarg.test, then all possible values must either be listed > in some EXTRA_*LIBRARIES variable, or the user must specify a rule to > update the library.) > >> Since there >> might be 3rd party dependencies assuming the libhell0.a form, it >> might be good if Automake also copied the hell0.lib file to >> libhell0.a after creating libraries of the hell0.lib form to satisfy >> those dependencies. (Or a symlink might suffice?) > > I haven't made up my mind yet on the exact semantics. There are a few > possibilities, but portability and practicality will probably rule some > of these out. > > ATM I'm wondering whether completing AM_PROG_AR first or looking into > this would be better. AM_PROG_AR creates lots of fallout in Libtool > beside the remaining work in Automake, and fixing Libtool so that it > works well with older and newer Automake isn't exactly trivial. Hi Ralf, Yes, let's put this at the back of the queue. I just figured I'd bring it up, and it was nice to hear that it isn't completely impossible. Cheers, Peter
