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
