Jacob Meuser <jakemsr <at> jakemsr.com> writes: > On Tue, Dec 06, 2005 at 10:27:59PM +0100, Marc Espie wrote: > > On Tue, Dec 06, 2005 at 09:59:19PM +0100, Marc Espie wrote: > > > I am currently checking that at least kdelibs is happy with this diff > > > and standard libtool, so far, so good...
Thanks for the patch! > > The cincher is, > > libtool --tag=disable-static --tag=CXX > > does not work, since --tag=CXX will redefine build_old_libs to yes. > > you mean in the TAGs section? or deep inside libtool? Yes, in the TAGs section it will. > is this with modules and libraries, or modules only? Doesn't matter. > what problem does it actually cause? only static? static and > dynamic but static gets chosen when dynamic is preferred? It's just that --tag=CXX loads a set of variables, which includes build_old_libs. > and it looks like build_libtool_libs=yes will (should anyway) > override build_old_libs=yes. Well, I'm not sure how to solve this. If you pass --tag=disable-static --tag=disable-shared or --tag=CC --tag=CXX --tag=F77 what would you expect to happen? In those cases, taking the last one given seems sane to me. But we already break down here: we don't move from static-only to shared-only. So my first thought was just to document that the last tag decides, and that going from static to shared won't work. But then again I don't know how KDE libs build rules are generated, and it might not be easy to change the order of the arguments for a set of rules. --tag=CXX --tag=disable-static should do what you want. Is that sufficient? If not, we need to create two more variables want_old_libs/want_libtool_libs to differentiate between capability and desired operation. Cheers, Ralf
