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
__________________________
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
