On Wed, Dec 07, 2005 at 08:45:51AM +0000, Ralf Wildenhues wrote: > 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
It's not easy to change stuff there, not at all. > 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. Yes, that's the way I want. And this is the kind of patch I'm working on...
