[CMake] LIBRARY_OUTPUT_PATH & swig modules

Brad King brad.king at kitware.com
Fri Jul 22 13:07:39 EDT 2005


Clinton Stimpson wrote:
> I've got an application where we use LIBRARY_OUTPUT_PATH to make all the 
> libraries go into one directory.
> However, we don't want the swig modules to go there, but to stay in 
> their respective directories.
> How is the best way to do this?

If the swig modules are built in their own subtree then you can do

SET(LIBRARY_OUTPUT_PATH)

in that tree to remove it.  However, I have found that it is easier to 
have all the binaries next to each other.  If the wrapper modules depend 
on other shared libraries it is nice to have them in the same directory. 
  This is because windows searches the directory containing a .dll for 
the .dlls on which it depends.  On UNIX this behavior can be 
approximated by putting '.' in the rpath and setting up a wrapper script 
to always set the cwd correctly before loading the module.

> On the other hand, if I let the swig modules follow LIBRARY_OUTPUT_PATH, 
> the .py and .so file get separated when they aren't supposed to be.
> That is because the UseSWIG.cmake file uses CMAKE_CURRENT_BINARY_DIR 
> instead of LIBRARY_OUTPUT_PATH for where to generate the .py file that 
> is associated with the .so library.

In order to support smooth python wrapper imports from both a build tree 
and an install tree (possibly in a movable location) I usually create a 
configured myprojbase.py script that contains code to help find and load 
the real wrappers.  See ITK's script:

http://www.itk.org/cgi-bin/viewcvs.cgi/Wrapping/CSwig/Python/itkbase.py.in?rev=HEAD&root=Insight&view=auto

The script gets configured twice.  Once for the build tree and once for 
the install tree.  It has knowledge of the proper places to look for 
libraries.

-Brad


More information about the CMake mailing list