[CMake] Multiple libraries, same name...

[Alan W. Irwin]

On 2010-02-02 00:39-0500 Ryan C. Gordon wrote:

>
> I'm trying to add bindings for various scripting languages to my library 
> PhysicsFS ( http://icculus.org/physfs/ ), and I'm having some trouble.
>
> Eventually I end up with something like this abbreviated example for the Perl 
> bindings...
>
>    # This is the actual main library, not the binding.
>    ADD_LIBRARY(physfs SHARED whatever)
>
>    # This is the binding.
>    ADD_LIBRARY(physfs-perl SHARED "physfs-perl.c")
>    TARGET_LINK_LIBRARIES(physfs-perl physfs)
>    SET_TARGET_PROPERTIES(physfs-perl PROPERTIES OUTPUT_NAME "physfs")
>    INSTALL(TARGETS physfs-perl LIBRARY DESTINATION "${_INSTALLPATH}")
>
> ...the problem is, of course, the OUTPUT_NAME. It ends up overwriting the 
> libphysfs.so for the base library. The problem, though, is that you need this 
> library name for Perl. I could keep the original name of physfs-perl, but 
> that is awkward for actual usage in perl...
>
>   # I assume the '-' confuses this, but you get the point.
>   use physfs-perl;
>   physfs-perl::init("");
>
> ...I'd rather that be the more concise "use physfs;" etc, but that requires 
> the same library name as the base library, installed in a different path that 
> Perl likes.
>
> Is there some way to get cmake to store linker output somewhere else? Like, 
> the physfs target puts its final shared libraries in CMakeFiles/physfs.dir, 
> and the perl ones go in CMakeFiles/physfs-perl.dir? Currently they all go in 
> the base of the binaries directory, even if this proves catastrophic. Perhaps 
> they can have different file names but can be overridden in the INSTALL 
> directive?
>
> Specifying a path on OUTPUT_NAME confuses the build system, so that's not the 
> right route, I think.
>
> This is with CMake 2.8.0.

I suggest you should build your perl bindings in a separate subdirectory.
Then there are no nameclashes with anything else at least until the install,
and you have indicated an install nameclash is not a problem for your perl
bindings because those bindings have a unique position in the install tree.
Also, there is a certain logical neatness to keeping different bindings in
different subdirectories with separate small CMakeLists.txt files rather
than having one huge CMakeLists.txt file.  Anyhow, the approach of splitting
up CMakeList.txt files and source trees into separate subdirectories is
quite common and also helps to reduce scope issues for the CMake language.

Hope this helps.

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
__________________________