[CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
Hi, I just started to add swig support to our project http://sourceforge.net/projects/sdif. The project supports swig bindings to perl, python and java. I instantly tried the available cmake modules: notably FindSWIG.cmake and FindPerlLibs.cmake I was pretty astonished to find that these two macros do not work at all, because most of the important information that is necessary to find the components is hardcoded using fixed version numbers (that are already out of date) I added patched version of these macros to bug reports 4145 4146 in the cmake bug database. These patched versions are completely backwards compatible (they use the wrong and fixed path locations first before they fall back to the new scheme and use the same variables to communicate results) The idea of the new procedure is to base everything on the FIND_PROGRAM macros that searches for the perl/swig binaries and (if found) asks the binary via inplace scripts (perl)/command line options (swig) all the directory locations that are needed. This approach is very flexible because by simply setting PERL_EXECUTABLE or SWIG_EXECUTABLE on the command line (or the cmake gui) one can select an arbitrary perl/swig version that is installed on the system. Any comments or volunteers to try? -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On 12/5/06, Axel Roebel <[EMAIL PROTECTED]> wrote:
Hi,
I just started to add swig support to our project
http://sourceforge.net/projects/sdif. The project supports
swig bindings to perl, python and java.
I instantly tried the available
cmake modules: notably FindSWIG.cmake
and FindPerlLibs.cmake
I was pretty astonished to find that these
two macros do not work at all, because most of the
important information that is necessary
to find the components is hardcoded
using fixed version numbers (that are already out of date)
I added patched version of these macros to bug reports 4145
4146 in the cmake bug database. These patched versions
are completely backwards compatible (they use the wrong and fixed path
locations first before they fall back to the new scheme and use
the same variables to communicate results)
The idea of the new procedure is to base everything on the FIND_PROGRAM
macros that searches for the perl/swig binaries
and (if found) asks the binary via inplace scripts (perl)/command line options
(swig) all the directory locations that are needed.
This approach is very flexible because by simply setting PERL_EXECUTABLE or
SWIG_EXECUTABLE on the command line (or the cmake gui)
one can select an arbitrary perl/swig version
that is installed on the system.
The following concerns `UseSWIG.cmake':
Thanks for what you did, it's a long time this module had to be
rewritten. I guess you're absolutely right to use features provided by
a tool to find its own config directories. I didn't notice that swig
had this option.
Here are some comments (without testing your module):
I guess 2 calls to `FIND_PATH' on the same file `swig.swg' is weird, why don't
you make the EXECUTE_PROCESS before to retrieve the directory given by
`swig -swiglib' and finally make the FIND_PATH of `swig.swg'?
1. Look for swig executable
2. use `swig -swiglib' to get the swiglib path
3. FIND_PATH(SWIG_DIR swig.swg ${SWIG_outlib} /usr/share/swig1.3 ...)
# - Find SWIG
# This module finds an installed SWIG. It sets the following variables:
# SWIG_FOUND - set to true if SWIG is found
# SWIG_DIR - the directory where swig is installed
# SWIG_EXECUTABLE - the path to the swig executable
SET(SWIG_FOUND FOOBAR)
I guess `FALSE' would be cleaner.
FIND_PATH(SWIG_DIR
SWIGConfig.cmake
/usr/share/swig1.3
/usr/lib/swig1.3
/usr/local/share/swig1.3)
On Linux, mine are installed in /usr/local/swig/1.3.{29,30,31} without
specifying anything strange during the `./configure'. Maybe you should
add this paths to.
FIND_PATH(SWIG_DIR
swig.swg
/usr/share/swig1.3
/usr/lib/swig1.3
/usr/local/share/swig1.3)
IF(EXISTS ${SWIG_DIR})
IF("x${SWIG_DIR}x" STREQUAL "x${CMAKE_ROOT}/Modulesx")
MESSAGE("SWIG_DIR should not be modules subdirectory of CMake")
ENDIF("x${SWIG_DIR}x" STREQUAL "x${CMAKE_ROOT}/Modulesx")
IF(EXISTS ${SWIG_DIR}/SWIGConfig.cmake)
INCLUDE(${SWIG_DIR}/SWIGConfig.cmake)
SET(SWIG_FOUND 1)
ELSE(EXISTS ${SWIG_DIR}/SWIGConfig.cmake)
FIND_PROGRAM(SWIG_EXECUTABLE
NAMES swig-1.3 swig
PATHS ${SWIG_DIR} ${SWIG_DIR}/.. ${SWIG_DIR}/../../bin /usr/bin
/usr/local/bin )
SET(SWIG_USE_FILE ${CMAKE_ROOT}/Modules/UseSWIG.cmake)
ENDIF(EXISTS ${SWIG_DIR}/SWIGConfig.cmake)
ELSE(EXISTS ${SWIG_DIR})
FIND_PROGRAM(SWIG_EXECUTABLE swig )
MESSAGE(STATUS "SWIG_EXECUTABLE -- ${SWIG_EXECUTABLE}")
Personnaly I don't like talktative modules. I expect:
IF(SWIG_FIND_QUIETLY)
MESSAGE(STATUS)
ENDIF(SWIG_FIND_QUIETLY)
Whatever you can put the MESSAGE commands at the end of the file to
summary what happened.
IF(NOT "${SWIG_EXECUTABLE}" STREQUAL "SWIG_EXECUTABLE-NOTFOUND")
IF(NOT SWIG_EXECUTABLE)
is enough, isn't it?
SET(SWIG ${SWIG_EXECUTABLE})
EXECUTE_PROCESS(COMMAND ${SWIG}-swiglibOUTPUT_VARIABLE
SWIG_DIR_TMP)
The command can fail, however it's common to use lower-case for internal
variables:
EXECUTE_PROCESS(COMMAND ${SWIG_EXECUTABLE} -swiglib
OUTPUT_VARIABLE SWIG_swiglib_output
ERROR_VARIABLE SWIG_swiglib_error
RESULT_VARIABLE SWIG_swiglib_result
)
IF(NOT ${SWIG_swiglib_result} EQUAL 0)
MESSAGE(SEND_ERROR "Command \"${SWIG_EXECUTABLE} -swiglib\" failed
with output:\n${SWIG_swiglib_error}")
ENDIF(NOT ${SWIG_swiglib_result} EQUAL 0)
I've got a strange behavior on Windows:
$ which swig
/cygdrive/c/Program Files/swigwin-1.3.31/swig
$ swig -swiglib
c:\Program Files\swigwin-1.3.31\Lib
C:/msys/1.0/local/share/swig/1.3.31
$
... so you have to consider that the command can write several paths.
The best thing would be to only keep the path that "match" the
SWIG_EXECUTABLE path.
I guess a
STRING(REGEX REPLACE "[\n]" ";" SWIG_swiglib_output ${SWIG_swiglib_output})
should be enough to separate the string in several arguments. As there
can be spaces in the paths, you can't use the SEPARATE_ARGUMENT command.
STRING(REGEX REPLACE "[\n\r]" "" SWIG_DIR_TMP_NOCR ${SWIG_DIR_TMP})
FIND_PATH(SWIG_DIR swig.swg PATHS "${SWIG_DIR_TMP_NOCR}")
IF(EXI
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Wednesday 06 December 2006 00:58, Tristan Carel wrote:
> On 12/5/06, Axel Roebel <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I just started to add swig support to our project
> > http://sourceforge.net/projects/sdif. The project supports
> > swig bindings to perl, python and java.
> >
> > I instantly tried the available
> > cmake modules: notably FindSWIG.cmake
> > and FindPerlLibs.cmake
> >
> > I was pretty astonished to find that these
> > two macros do not work at all, because most of the
> > important information that is necessary
> > to find the components is hardcoded
> > using fixed version numbers (that are already out of date)
> >
> > I added patched version of these macros to bug reports 4145
> > 4146 in the cmake bug database. These patched versions
> > are completely backwards compatible (they use the wrong and fixed path
> > locations first before they fall back to the new scheme and use
> > the same variables to communicate results)
> >
> > The idea of the new procedure is to base everything on the FIND_PROGRAM
> > macros that searches for the perl/swig binaries
> > and (if found) asks the binary via inplace scripts (perl)/command line
> > options (swig) all the directory locations that are needed.
> >
> > This approach is very flexible because by simply setting PERL_EXECUTABLE
> > or SWIG_EXECUTABLE on the command line (or the cmake gui)
> > one can select an arbitrary perl/swig version
> > that is installed on the system.
>
> The following concerns `UseSWIG.cmake':
>
> Thanks for what you did, it's a long time this module had to be
> rewritten. I guess you're absolutely right to use features provided by
> a tool to find its own config directories. I didn't notice that swig
> had this option.
>
> Here are some comments (without testing your module):
> I guess 2 calls to `FIND_PATH' on the same file `swig.swg' is weird, why
> don't you make the EXECUTE_PROCESS before to retrieve the directory given
> by `swig -swiglib' and finally make the FIND_PATH of `swig.swg'?
I preserved what was in the original FindSWIG and drop in my new method only
if the old one fails. If you suggest to remove the old version completely
I am all for it.
> 1. Look for swig executable
> 2. use `swig -swiglib' to get the swiglib path
> 3. FIND_PATH(SWIG_DIR swig.swg ${SWIG_outlib} /usr/share/swig1.3 ...)
could you tell me why you add this path
/usr/share/swig1.3 ?
> > # - Find SWIG
> > # This module finds an installed SWIG. It sets the following variables:
> > # SWIG_FOUND - set to true if SWIG is found
> > # SWIG_DIR - the directory where swig is installed
> > # SWIG_EXECUTABLE - the path to the swig executable
> > SET(SWIG_FOUND FOOBAR)
>
> I guess `FALSE' would be cleaner.
I took what was there. I can change that for the better I agree.
> > FIND_PATH(SWIG_DIR
> > SWIGConfig.cmake
> > /usr/share/swig1.3
> > /usr/lib/swig1.3
> > /usr/local/share/swig1.3)
>
> On Linux, mine are installed in /usr/local/swig/1.3.{29,30,31} without
> specifying anything strange during the `./configure'. Maybe you should
> add this paths to.
I am repeating me here. The old version had these fixed paths, which I find
complete nonsense. I don't see why why we would want to make this list
longer then necessary. Everything put into configure
should be mirrored in the path the swig binary reports.
> > FIND_PATH(SWIG_DIR
> > swig.swg
> > /usr/share/swig1.3
> > /usr/lib/swig1.3
> > /usr/local/share/swig1.3)
> > IF(EXISTS ${SWIG_DIR})
> > IF("x${SWIG_DIR}x" STREQUAL "x${CMAKE_ROOT}/Modulesx")
> > MESSAGE("SWIG_DIR should not be modules subdirectory of CMake")
> > ENDIF("x${SWIG_DIR}x" STREQUAL "x${CMAKE_ROOT}/Modulesx")
> >
> > IF(EXISTS ${SWIG_DIR}/SWIGConfig.cmake)
> > INCLUDE(${SWIG_DIR}/SWIGConfig.cmake)
> > SET(SWIG_FOUND 1)
> > ELSE(EXISTS ${SWIG_DIR}/SWIGConfig.cmake)
> > FIND_PROGRAM(SWIG_EXECUTABLE
> > NAMES swig-1.3 swig
> > PATHS ${SWIG_DIR} ${SWIG_DIR}/.. ${SWIG_DIR}/../../bin /usr/bin
> > /usr/local/bin ) SET(SWIG_USE_FILE ${CMAKE_ROOT}/Modules/UseSWIG.cmake)
> > ENDIF(EXISTS ${SWIG_DIR}/SWIGConfig.cmake)
> > ELSE(EXISTS ${SWIG_DIR})
> > FIND_PROGRAM(SWIG_EXECUTABLE swig )
> > MESSAGE(STATUS "SWIG_EXECUTABLE -- ${SWIG_EXECUTABLE}")
>
> Personnaly I don't like talktative modules. I expect:
> IF(SWIG_FIND_QUIETLY)
> MESSAGE(STATUS)
> ENDIF(SWIG_FIND_QUIETLY)
>
> Whatever you can put the MESSAGE commands at the end of the file to
> summary what happened.
I don't like to have a special solution only for FindSWIG.
However, I am open to the suggestion to
remove the message completely
> > IF(NOT "${SWIG_EXECUTABLE}" STREQUAL "SWIG_EXECUTABLE-NOTFOUND")
>
> IF(NOT SWIG_EXECUTABLE)
> is enough, isn't it?
>
You're right
> > SET(SWIG ${SWIG_EXECUTABLE})
> > EXECUTE_PROCESS(COMMAND ${SWIG}-swiglibOUTPUT_VARIABLE
> > SWIG_DIR_TMP)
>
> The command can fail, however it's common to use lower-case for internal
> variables:
>
> E
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
Axel Roebel wrote:
1. Look for swig executable
2. use `swig -swiglib' to get the swiglib path
3. FIND_PATH(SWIG_DIR swig.swg ${SWIG_outlib} /usr/share/swig1.3 ...)
could you tell me why you add this path
/usr/share/swig1.3 ?
This is a an old module, the FIND_* stuff has changed a lot since then.
For instance, the FIND_* stuff automatically adds /usr/bin, /usr/local/bin,
and other system paths for the architecture that is running. What is needed
is the PATH_SUFFIXES option to FIND_* so that cmake will know to
look for swigVersionNumbers in all those system paths. So, the listed paths
in the FIND_* are not the whole picture, and in most cases are not even
needed at all.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
Bill Hoffman wrote:
> Axel Roebel wrote:
> >> 1. Look for swig executable
> >> 2. use `swig -swiglib' to get the swiglib path
> >> 3. FIND_PATH(SWIG_DIR swig.swg ${SWIG_outlib} /usr/share/swig1.3 ...)
> >
> > could you tell me why you add this path
> > /usr/share/swig1.3 ?
>
> This is a an old module, the FIND_* stuff has changed a lot since then.
> For instance, the FIND_* stuff automatically adds /usr/bin, /usr/local/bin,
> and other system paths for the architecture that is running. What is
> needed is the PATH_SUFFIXES option to FIND_* so that cmake will know to
> look for swigVersionNumbers in all those system paths. So, the listed
> paths in the FIND_* are not the whole picture, and in most cases are not
> even needed at all.
You are seriously suggesting to add something like
FIND_PATH(SWIG_DIR swig.swg PATH_SUFFIXES share/swig/1.3.29 share/swig/1.3.30
share/swig/1.3.30 share/swig/1.3.31 share/swig/1.3.31 share/swig/1.3.32
share/swig/1.3.33 share/swig/1.3.34 share/swig/1.3.35
share/swig/1.4.0 share/swig/1.4.1 share/swig/1.4.2
)
instead of
FIND_PATH(SWIG_DIR swig.swg PATH ${SWIG_outlib})
knowing that apparently some month ago (or for some
operating systems) it was
share/swig1.3
that one had to use?
It seems to me that the only reliable way here
is the executable. If the executable does not know the installation directory
it cannot do anything and we should consider SWIG to be not installed.
Before I update the version in the bug tracker I would like to know
whether having
FIND_PATH(SWIG_DIR SWIGConfig.cmake PATH ${SWIG_outlib})
does make any sense in a FindSWIG.cmake.
From the documentation I understand that
in case the project provides a SWIGConfig.cmake
it should have set SWIG_DIR already and
FindSWIG would not have been called?
Cheers,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Wednesday 06 December 2006 17:36, Axel Roebel wrote: > > I will test the module tomorrow. > > Could you please put a RC2 of the `FindSWIG.cmake' on the bug tracker? > > That may take a day or too. > > I'll let you know. There it is, called FindSWIG.cmake-2 It should take care of all your comments, please have a look. I would especially be interested to hear if it works on windows. I can only try linux and Mac OS X Thanks, -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On 2006-12-07 19:41+0100 Axel Roebel wrote:
On Wednesday 06 December 2006 17:36, Axel Roebel wrote:
I will test the module tomorrow.
Could you please put a RC2 of the `FindSWIG.cmake' on the bug tracker?
That may take a day or too.
I'll let you know.
There it is, called FindSWIG.cmake-2
It should take care of all your comments,
please have a look. I would especially be
interested to hear if it works on windows.
I can only try linux and Mac OS X
Thanks Axel for your improvements to FindSWIG.cmake. The old version has
been the source of several PLplot complaints about not being able to find
installed versions of swig. Your use of swig -swiglib to get the required
directory information is a big step forward.
I tried out FindSWIG.cmake-2 on Linux, and (as expected) all was well
with PLplot.
The only minor issue I have with it, is I believe your success message does
not give enough information for the case where there is a choice of various
versions of swig.
Therefore, I would replace
MESSAGE(STATUS "using swig ${SWIG_DIR}")
with
MESSAGE(STATUS "using ${SWIG_EXECUTABLE} with SWIG_DIR = ${SWIG_DIR}")
I hope the CMake developers adopt your improved version of FindSWIG.cmake
for the next cmake release.
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 Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On 12/7/06, Axel Roebel <[EMAIL PROTECTED]> wrote:
On Wednesday 06 December 2006 17:36, Axel Roebel wrote:
> > I will test the module tomorrow.
> > Could you please put a RC2 of the `FindSWIG.cmake' on the bug tracker?
>
> That may take a day or too.
>
> I'll let you know.
There it is, called FindSWIG.cmake-2
It should take care of all your comments,
please have a look. I would especially be
interested to hear if it works on windows.
I can only try linux and Mac OS X
Cool!
The version works fine on Windows with 1.3.{29,30,31}
However I've got several comments
2. if the Swig executable version is changed, SWIG_DIR and
SWIG_VERSION are not updated. But as there are computed thanks to a
EXECUTE_PROCESS, if SWIG_EXECUTABLE changes, SWIG_DIR and SWIG_VERSION
must be updated.
2. I'm maybe paranoid, but I guess all internal variables declared by
a module should be prefixed by the module's name.
3. in the CMake/Modules/readme.txt, you can read:
"If the QUIET option is given to the command it will set the variable
XXX_FIND_QUIETLY to true before loading the FindXXX.cmake module."
but you use: FIND_SWIG_QUIETLY
4. Previous version only use SWIG_EXECUTABLE, there is no need to
introduce a new variable SWIG.
I put a third version of the bug tracker.
http://public.kitware.com/Bug/bug.php?op=show&bugid=4145
Thank you
--
Tristan Carel
Music with dinner is an insult both to the cook and the violinist.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Thursday 07 December 2006 20:37, Tristan Carel wrote:
> On 12/7/06, Axel Roebel <[EMAIL PROTECTED]> wrote:
> > On Wednesday 06 December 2006 17:36, Axel Roebel wrote:
> > > > I will test the module tomorrow.
> > > > Could you please put a RC2 of the `FindSWIG.cmake' on the bug
> > > > tracker?
> > >
> > > That may take a day or too.
> > >
> > > I'll let you know.
> >
> > There it is, called FindSWIG.cmake-2
> >
> > It should take care of all your comments,
> > please have a look. I would especially be
> > interested to hear if it works on windows.
> > I can only try linux and Mac OS X
>
> Cool!
>
> The version works fine on Windows with 1.3.{29,30,31}
>
> However I've got several comments
Hi Tristan,
> 2. if the Swig executable version is changed, SWIG_DIR and
> SWIG_VERSION are not updated. But as there are computed thanks to a
> EXECUTE_PROCESS, if SWIG_EXECUTABLE changes, SWIG_DIR and SWIG_VERSION
> must be updated.
ok great
> 2. I'm maybe paranoid, but I guess all internal variables declared by
> a module should be prefixed by the module's name.
>
> 3. in the CMake/Modules/readme.txt, you can read:
> "If the QUIET option is given to the command it will set the variable
> XXX_FIND_QUIETLY to true before loading the FindXXX.cmake module."
>
> but you use: FIND_SWIG_QUIETLY
yes in fact I didn't read that file.
> 4. Previous version only use SWIG_EXECUTABLE, there is no need to
> introduce a new variable SWIG.
>
>
> I put a third version of the bug tracker.
> http://public.kitware.com/Bug/bug.php?op=show&bugid=4145
Fine - error handling was obviously sub optimal in my code.
The last version works for me, as well.
Thanks for the feedback.
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Thursday 07 December 2006 22:57, Axel Roebel wrote:
> > 3. in the CMake/Modules/readme.txt, you can read:
> > "If the QUIET option is given to the command it will set the variable
> > XXX_FIND_QUIETLY to true before loading the FindXXX.cmake module."
> >
> > but you use: FIND_SWIG_QUIETLY
>
> yes in fact I didn't read that file.
I have now read all the stuff in the readme I find that the handling of
REQUIRED and QUIETKY flags was still not correct in FindSWIG.cmake
Apparently this is a copy and paste error and many of the Find packages
are not dealing with these flags correctly.
The FindBoost.cmake for example does the same as the last version of the
FindSWIG.cmake
IF(NOT Boost_FOUND)
IF(NOT Boost_FIND_QUIETLY)
MESSAGE(STATUS "Boost was not found. ${BOOST_DIR_MESSAGE}")
ELSE(NOT Boost_FIND_QUIETLY)
IF(Boost_FIND_REQUIRED)
MESSAGE(FATAL_ERROR "Boost was not found. ${BOOST_DIR_MESSAGE}")
ENDIF(Boost_FIND_REQUIRED)
ENDIF(NOT Boost_FIND_QUIETLY)
ENDIF(NOT Boost_FOUND)
This boils down to having a fatal error only if the QUIET flag was given
together with the REQUIRED flag, which I suppose was not intended.
In FindVTK.cmake we see
IF(NOT VTK_FIND_QUIETLY)
MESSAGE(FATAL_ERROR ${VTK_DIR_MESSAGE})
ELSE(NOT VTK_FIND_QUIETLY)
IF(VTK_FIND_REQUIRED)
MESSAGE(FATAL_ERROR ${VTK_DIR_MESSAGE})
ENDIF(VTK_FIND_REQUIRED)
ENDIF(NOT VTK_FIND_QUIETLY)
which means we always get a fatal error which is also not what the readme
suggests.
I updated the FindSWIG.cmake to do
IF(NOT SWIG_FOUND)
IF(NOT SWIG_FIND_QUIETLY)
IF(SWIG_FIND_REQUIRED)
MESSAGE(FATAL_ERROR "SWIG was not found. Please specify Swig executable
location")
ELSE(SWIG_FIND_REQUIRED)
MESSAGE(STATUS "SWIG was not found. Please specify Swig executable
location")
ENDIF(SWIG_FIND_REQUIRED)
ENDIF(NOT SWIG_FIND_QUIETLY)
ENDIF(NOT SWIG_FOUND)
which seems me to do what the readme suggests with the interpretation that
QUIET takes precedence over REQUIRED.
Alain Irwin wrote:
> Therefore, I would replace
>
> MESSAGE(STATUS "using swig ${SWIG_DIR}")
>
> with
>
> MESSAGE(STATUS "using ${SWIG_EXECUTABLE} with SWIG_DIR = ${SWIG_DIR}")
Because every project maintainer will probably have its own desires (from
Tristan who wants nothing
to Alan who wants more) I removed all positive status messages in the last
version.
The calling CMakeLists.txt can output the desired
information using the result variables much more flexible then the
FindSWIG.cmake could
do.
Cheers,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
Axel Roebel wrote: > Hi, > Hello, > I just started to add swig support to our project > http://sourceforge.net/projects/sdif. The project supports > swig bindings to perl, python and java. > > I instantly tried the available > cmake modules: notably FindSWIG.cmake > and FindPerlLibs.cmake > > I was pretty astonished to find that these > two macros do not work at all, because most of the > important information that is necessary > to find the components is hardcoded > using fixed version numbers (that are already out of date) Maybe you want to take a look at http://svn.gpsdrive.cc/gpsdrive/trunk/cmake/Modules/FindPerlLibs.cmake -- andreas -- http://www.cynapses.org/ - cybernetic synapses signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Monday 18 December 2006 13:43, Andreas Schneider wrote: > Axel Roebel wrote: > > Hi, > > Hello, > > > I just started to add swig support to our project > > http://sourceforge.net/projects/sdif. The project supports > > swig bindings to perl, python and java. > > > > I instantly tried the available > > cmake modules: notably FindSWIG.cmake > > and FindPerlLibs.cmake > > > > I was pretty astonished to find that these > > two macros do not work at all, because most of the > > important information that is necessary > > to find the components is hardcoded > > using fixed version numbers (that are already out of date) > > Maybe you want to take a look at > > http://svn.gpsdrive.cc/gpsdrive/trunk/cmake/Modules/FindPerlLibs.cmake > Hi Andreas, obviously you've found a simpler method to achieve the same goal and your tests are more complete. It seems to me, however, that it has the same weaknesses as my current version - libperl.so is not found (at least not on Fedora and redhat CentOS, I didn't recognize because swig does not need it) - changing the perl interpreter would not change the libraries and include paths (as Tristan pointed out for my second FindSWIG.cmake) If I find the time I will fix these issues and put them into the bug fix. I will use your simpler version of determining perl variables and will add the variables you test as well. Thanks for the feedback. > -- andreas -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
Axel Roebel wrote: > > Hi Andreas, Hi Axel, > > obviously you've found a simpler method to achieve the same goal > and your tests are more complete. It seems to me, however, that it has the > same weaknesses as my current version > > - libperl.so is not found (at least not on Fedora and redhat CentOS, I didn't > recognize because swig does not need it) Why isn't it found, what path do they use? > - changing the perl interpreter would not change the libraries and include > paths (as Tristan pointed out for my second FindSWIG.cmake) > > If I find the time I will fix these issues and put them into the bug fix. > I will use your simpler version of determining perl variables and will > add the variables you test as well. just use my FindPerl.cmake and modify it :) -- andreas -- http://www.cynapses.org/ - cybernetic synapses signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Friday 22 December 2006 00:11, Andreas Schneider wrote: > Axel Roebel wrote: > > Hi Andreas, > > Hi Axel, Happy new year everybody! > > obviously you've found a simpler method to achieve the same goal > > and your tests are more complete. It seems to me, however, that it has > > the same weaknesses as my current version > > > > - libperl.so is not found (at least not on Fedora and redhat CentOS, I > > didn't recognize because swig does not need it) > > Why isn't it found, what path do they use? same as the include files siter.roebel: (~) 498> locate libperl.so /usr/lib/perl5/5.8.2/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.1/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so > > - changing the perl interpreter would not change the libraries and > > include paths (as Tristan pointed out for my second FindSWIG.cmake) > > > > If I find the time I will fix these issues and put them into the bug fix. > > I will use your simpler version of determining perl variables and will > > add the variables you test as well. > > just use my FindPerl.cmake and modify it :) Thanks, I'll do that. Axel > -- andreas -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
