[CMake] Convenience lib vs static library

[Alan W. Irwin]

On 2008-11-23 12:51+0100 Hendrik Sattler wrote:

> Am Sunday 23 November 2008 10:35:03 schrieb Andreas Pakulat:
>> On 23.11.08 11:24:23, Ioan Calin Borcoman wrote:
>>> Would it be possible to add support for libtool in a cmake module? I
>>> understand that this would be against cmake's policy of not depending
>>> on external apps, but it could be a transient solution until full
>>> fledged support for convenience libs is added into cmake.
>>
>> PS: What has been discussed (and afaik even requested via cmake's
>> bugtracker) is to allow access to the actual created object files. That
>> way you could have the same files included in >1 shared library and would
>> still save the compilation time.

Andreas, you can get such access (at least on Unix) by using the appropriate
"ar" command for static libraries.  However, you normally don't need to do
that.  If you are using the same code in lots of different executables (one
of the motivations behind libtool's convenience library idea) then you can
link each executable to the static library with the common code as was
stated much earlier in this thread.  In short, for static object modules
there is essentially no practical difference between libtool's convenience
libraries and static libraries.

>
> Yes. Something like a unlinked (virtual) library. Depending on it would not
> link that library but its object files. Shouldn't be that complicated but has
> its pitfalls: position independent code (PIC) is used for object going to a
> shared library but not for objects going to an executable or static library
> (unless you want to link the static library into a shared library).

As an add-on to what Hendrik has said for the much more interesting shared
object module case, I want to emphasize that the fundamental issue is not
access to the object modules (since you can always gain access to individual
object modules from a static library), but instead is the compiler options
used to create the shared object modules.  Assuming you want to link the
shared object modules into a number of different shared libraries (another
motivation behind libtool's convenience libraries), then you need to use the
same compiler options as for shared object modules that are being linked
directly into a shared library, and the problem is those options (e.g., to
option to specify PIC) are strongly platform dependent. CMake knows what
those compiler options are for all Unix platforms for shared object modules
that are put into shared libraries, but it doesn't (yet) have a mechanism to
provide those platform-dependent compile options for code that is being
stored in a special static library that will be linked by a shared library.

I believe that CMake option is all you really need to provide the equivalent
of libtool's convenience library in the shared linking case.  For example,
assuming you have a number of different shared libraries with common code
compiled with shared object module options into a special static library,
then linking those shared libraries to that special static library should be
all you need. However, I have never tried this in practice so I hope
somebody with practical experience in such linking will confirm, extend or
correct (if necessary) what I have said.

If my ideas are confirmed, then I hope the CMake developers move forward
with implementing a special static library option to compile everything in
that library with shared object module compile options.  The reason why I
think this is important is the lack of an equivalent to convenience
libraries for the shared object module case is the stated reason why some
major software projects will not move to CMake. At least that has been my
experience when I tried to advocate moving from autotools to CMake in
various e-mail conversations with X, libcairo, and Battle of Wesnoth
developers.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________