On 2011-06-16 14:10-0400 Brad King wrote:
On 06/16/2011 12:54 PM, Alan W. Irwin wrote:
Brad has accepted this patch and closed the bug. However, I am
interested because PLplot uses swig-1.3 with no user reports of
problems (has done for years). I personally have never seen swig
finding problems for Linux and also a MinGW/MSYS/wine platform.
Furthermore, I cannot reproduce the bug even with the simple test
example above for my platform (Debian stable with CMake-2.8.4 that I
built myself, and swig version 1.3.40-3).
On the other hand, the patch does look correct to me. So, Brad, how
in the world does find_package(SWIG) work at all for both my Linux and
wine platforms? Or to put it another way, for what platforms (with
swig-1.3) will this bug be triggered (until the fix goes into a
release)?
The fix was obviously a modernization independent of any behavior correction
so I took the patch without actually verifying a behavior change. It might
well have worked before. Perhaps the submitter had other issues interacting
during testing.
Since you're looking at this anyway please verify that the new version
works for you!
Hi Brad (and Dave, see comment at end):
I have investigated further, and here is the situation.
CMake-2.8.5-rc2 shows the following FindSWIG.cmake difference with
CMake-2.8.4;
17a18
# Copyright 2011 Mathieu Malaterre <mathieu.malate...@gmail.com>
29c30
< FIND_PROGRAM(SWIG_EXECUTABLE swig)
---
FIND_PROGRAM(SWIG_EXECUTABLE swig2.0 swig)
According to the cmake documentation, that second version should be
interpreted as the short form:
find_program(<VAR> name1 [path1 path2 ...])
which worked for the original bug reporter with swig2.0 (since swig is
just interpreted as an additional path), but should not work for me
with swig (version 1.3). Strangely it does work for me although the
original bug reporter could not get it to work with swig version 1.3
on his platform (whatever that was).
So the situation is the original bug reporter's patch makes
FIND_PROGRAM in FindSWIG.cmake conform to the documentation and solves
a swig-1.3 regression from 2.8.4 on his platform (although somehow my
platform is avoiding that regression).
In any case, the second form is obviously wrong according to the
documentation, so it should do no harm and will
fix a regression from 2.8.4 on some platforms to use
FIND_PROGRAM(SWIG_EXECUTABLE NAMES swig2.0 swig)
instead. I have tested that change on my platform (as you requested),
and as expected (since it now conforms to the documented behaviour of
FIND_PROGRAM) it works for me. Since some CMake users (and PLplot
users) are bound to see the same regression as the original bug
reporter, I would highly recommend this regression fix goes into
2.8.5.
@Dave Cole:
I not only tested that cmake found swig-1.3 with the patched version
of CMake-2.8.5-rc2, but I also did a complete build and fairly
extensive test of PLplot with that version. That particular test
suite tests all our noninteractive plot devices for all our different
language bindings (some of which are configured with swig). All those
tests passed without issues so (patched) CMake-2.8.5 is looking good
from my perspective.
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
__________________________
_______________________________________________
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
