Re: patch: c/cxxflags for static libraries
Matt Broadstone wrote: Personally it would be useful to me to be able to have convenience libs supported again. I have posted a patch to this list converting khtml to use convenience libs. Why don't we figure out how to get this working with cmake? We have a test case.. Why do you need a convenience lib? It's just a bunch of .o anyways, so use them directly. CMake could create a virtual target, though. That might be useful. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpO7wZBAbITU.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
Simon Hausmann wrote: On Sunday 16. July 2006 20:31, Thiago Macieira wrote: [...] If you add a .o that happens to be in an ar archive into a shared library, you've got a convenience library, not a static library. In those cases, just link the .o once and for all. There's no need to create the archive. Yes, but as long as the build system offers this feature people will use it. So I suggest that we either drop the feature alltogether or we use -fPIC there as well. But offering it as feature that only works on i386 when linked into a final shared object is not a good idea IMHO. I agree: it shouldn't allow you to link a static library to a shared library. Problem solved. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpgdKNSzOdgR.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
Brad King wrote: For plain old ADD_LIBRARY, the STATIC option works on all platforms to create a static library. What is not supported is the convenience part that allows multiple static libraries to be linked to form a bigger static library, or all the objects in a static archive to be copied into a shared library whether they are referenced or not. Right. CMake shouldn't allow one to add a static library as a dependency for anything other than a final executable. I don't know if it does that or not, but it shouldn't. libtool allowed that because the dependency was recorded in the .la file. When the final executable was linked, the linking was actually performed. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgp5PnmA9UiM9.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
Thiago Macieira wrote: Brad King wrote: For plain old ADD_LIBRARY, the STATIC option works on all platforms to create a static library. What is not supported is the convenience part that allows multiple static libraries to be linked to form a bigger static library, or all the objects in a static archive to be copied into a shared library whether they are referenced or not. Right. CMake shouldn't allow one to add a static library as a dependency for anything other than a final executable. I don't know if it does that or not, but it shouldn't. libtool allowed that because the dependency was recorded in the .la file. When the final executable was linked, the linking was actually performed. The equivalent in CMake would be to just remove static libraries from the list of libraries put on the link line for a shared library. The static libraries should still be listed as dependencies so that when the executable links to the shared library it gets the static library too. Does this sound correct? -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
Brad King wrote: The equivalent in CMake would be to just remove static libraries from the list of libraries put on the link line for a shared library. The static libraries should still be listed as dependencies so that when the executable links to the shared library it gets the static library too. Does this sound correct? No. They should be completely forbidden. If you do it like that, it'll work for a shared library that is produced in the same cmake build. But it'll fail for a 3rd-party (from a different cmake build), since the dependency isn't recorded anywhere. Unless you're proposing to create and install .la files. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgp11ime2mgMX.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
Thiago Macieira wrote: Brad King wrote: The equivalent in CMake would be to just remove static libraries from the list of libraries put on the link line for a shared library. The static libraries should still be listed as dependencies so that when the executable links to the shared library it gets the static library too. Does this sound correct? No. They should be completely forbidden. If you do it like that, it'll work for a shared library that is produced in the same cmake build. But it'll fail for a 3rd-party (from a different cmake build), since the dependency isn't recorded anywhere. Unless you're proposing to create and install .la files. Sure it is recorded. Look at the EXPORT_LIBRARY_DEPENDENCIES command. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: patch: c/cxxflags for static libraries
On 7/18/06, Thiago Macieira [EMAIL PROTECTED] wrote: Matt Broadstone wrote: Personally it would be useful to me to be able to have convenience libs supported again. I have posted a patch to this list converting khtml to use convenience libs. Why don't we figure out how to get this working with cmake? We have a test case.. Why do you need a convenience lib? It's just a bunch of .o anyways, so use them directly. CMake could create a virtual target, though. That might be useful. Well its not so much that I want a convenience lib, as I want a logical breakdown of the parts within a whole. For me it makes a lot more sense to build khtml in its pieces: dom, ecma, java, html etc. and then link them together in the whole. Furthermore, when I've been using my patch to build khtml, when I make simple changes inside ecma/debugger I no longer have to build the entirety of khtml. This may be a problem with cmake, as this should not necesarily be the case considering I haven't touched code that affects all of khtml, but that's what happens. If we can find a way around this, ie. change the CMakeLists.txt for khtml in such a way that simple changes in each module do not affect the entirety of khtml, then that's a decent solution. But for now, on my box, doing it this way (convenience, modular, whatever you want to call it :) ) works better for me, and I simply thought it might work better for others as well. Cheers, Matt Broadstone -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
