[Dcmlib] [Fwd: Re: [CMake] LIBRARY_OUTPUT_PATH & swig modules]
mathieu.malaterre at kitware.com
Fri Jul 22 19:10:29 CEST 2005
Je garde celui la pour virer les fichier python .in
-------- Original Message --------
Subject: Re: [CMake] LIBRARY_OUTPUT_PATH & swig modules
Date: Fri, 22 Jul 2005 13:07:39 -0400
From: Brad King <brad.king at kitware.com>
To: Clinton Stimpson <clinton at elemtech.com>
CC: cmake at cmake.org
References: <42DFB5E2.8080709 at elemtech.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
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:
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
CMake mailing list
CMake at cmake.org
More information about the Dcmlib