[CMake] LIBRARY_OUTPUT_PATH & swig modules

Clinton Stimpson clinton at elemtech.com
Sat Jul 23 00:58:00 EDT 2005


Quoting Brad King <brad.king at kitware.com>:

> 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)

This is what we have been doing.  However, other things stop working when we
do this.  As in VTK, Rendering/CMakeLists.txt just references vtkCommon as a
library to link to.  CMake automatically knows where that library is and how
to link it into vtkRendering.  However, setting LIBRARY_OUTPUT_PATH for a
single directory breaks that.  Our workaround is to reference libraries by
their full path.  However, with CMake 2.2, parallel building introduces
another problem of not building dependents before the swig libs.

>
> in that tree to remove it.  However, I have found that it is easier 
> to have all the binaries next to each other.

Yes, I find it easier too.  I've been trying to push one of our project in
that direction.


> 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.

This app is an embedded python app (c++ main with python linked in).  So the
scenario is a touch different.  We have a choice or two more in library
locations and the whole system still works.

>
>> 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:

We do some special things to set up an install tree too.

My concern here is the things that don't work anymore when an individual
directory sets LIBRARY_OUTPUT_PATH.

Thanks,
Clint

>
> 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