View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015508CMakeModulespublic2015-04-09 23:492015-11-02 09:13
ReporterRPM 
Assigned To 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformLinuxOSCentOSOS Version6
Product VersionCMake 3.2.1 
Target VersionCMake 3.3Fixed in VersionCMake 3.3 
Summary0015508: UseSWIG->SWIG_ADD_MODULE doesn't correctly grab module name from source file
DescriptionIf the SWIG_MODULE_NAME is not set on the source file, the macro is supposed to try and determine the module name by performing a REGEX on the source file. This doesn't appear to work correctly.

The issue is that SWIG_GET_EXTRA_OUTPUT_FILES checks to see if the source file EXISTS, but does so with infile, which is an undefined operation if it is a relative path. The SWIG_ADD_SOURCE_TO_MODULE grabs the absolute path in swig_source_file_fullname, but then does not pass it on to SWIG_GET_EXTRA_OUTPUT_FILES. Making it pass the absolute path allows it to correctly find the file whether provided as relative or absolute.
TagsNo tags attached.
Attached Filestxt file icon CMakeLists.txt [^] (582 bytes) 2015-04-13 09:47 [Show Content]
? file icon example.i [^] (122 bytes) 2015-04-13 09:48
? file icon example.h [^] (41 bytes) 2015-04-13 09:48
c file icon example.c [^] (320 bytes) 2015-04-13 09:48
patch file icon UseSWIG.patch [^] (69 bytes) 2015-04-15 10:29 [Show Content]
? file icon UseSWIG.cmake [^] (12,370 bytes) 2015-04-15 10:29
patch file icon UseSWIG-bug0015508-1.patch [^] (542 bytes) 2015-04-15 10:30 [Show Content]

 Relationships

  Notes
(0038490)
Tuukka Pasanen (reporter)
2015-04-13 09:20

Is there any example CMake to test this?
(0038494)
RPM (reporter)
2015-04-13 09:53
edited on: 2015-04-13 09:53

I've attached a sample set of files based on the "SWIG and Python" documentation. In the CMakeLists file, if the file is passed as a full path, everything works fine. However, it does not work if provided a relative path and the error message is essentially non-existent, which makes it very difficult to debug:

$ mkdir BUILD
$ cd BUILD
$ cmake -DCMAKE_INSTALL_PREFIX=../INSTALL ../; make
-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonLibs: /opt/create/ptoolsrte/0.5.2alpha5/packages/Python-2.7.5/lib/libpython2.7.so (found version "2.7.5")
-- Found SWIG: /opt/create/ptoolsrte/0.5.2alpha5/packages/swig-2.0.10/bin/swig (found version "2.0.10")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mcnally/kestrel/swig/BUILD
[ 50%] Swig source
make[2]: *** [example.py] Error 1
make[1]: *** [CMakeFiles/_Example_wrap.dir/all] Error 2
make: *** [all] Error 2

(0038512)
Tuukka Pasanen (reporter)
2015-04-15 01:48
edited on: 2015-04-15 02:21

hm.. works for me with Swig 3.0.2. Can you test with that or are you stug with Swig 2.0.10? Does CentOS have SWIG 2.0.10 installed for production or are you using ptoolsrte Swig?

(0038513)
RPM (reporter)
2015-04-15 08:22

I don't see how the version of SWIG could affect the results, but I attempted it with the latest version of SWIG and got the same results (see end of this post). I inserted the following three lines at line 129 of UseSWIG.cmake to see what the macro was determining to be the module name:
  MESSAGE("infile: ${infile}")
  MESSAGE("_MODULE_NAME: ${_MODULE_NAME}")
  MESSAGE("SGEOF_module_basename: ${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}")

When run with a relative path, I get the following, which is wrong since example.i specifies that the module name is 'example_swig':
infile: example.i
_MODULE_NAME:
SGEOF_module_basename: example

When run with an absolute path, I get the following:
infile: /home/mcnally/kestrel/swig/example.i
_MODULE_NAME: example_swig
SGEOF_module_basename: example_swig

Regardless of behavior, inspection shows that if handed a relative path, that relative path will be passed to SWIG_GET_EXTRA_OUTPUT_FILES and subsequently tested with EXISTS, which is not good. According to the docs, the behavior of EXISTS is well-defined only for absolute paths.


Output with SWIG 3.0.5
----------------------
$ PATH=/home/mcnally/kestrel/swig/swig-3.0.5/INST/bin:$PATH cmake ../; make
-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonLibs: /opt/create/ptoolsrte/0.5.2alpha5/packages/Python-2.7.5/lib/libpython2.7.so (found version "2.7.5")
-- Found SWIG: /home/mcnally/kestrel/swig/swig-3.0.5/INST/bin/swig (found version "3.0.5")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mcnally/kestrel/swig/BUILD
[ 50%] Swig source
make[2]: *** [example.py] Error 1
make[1]: *** [CMakeFiles/_Example_wrap.dir/all] Error 2
make: *** [all] Error 2
(0038514)
Tuukka Pasanen (reporter)
2015-04-15 09:42

Could you launch with 'make VERBOSE=1' I like see what really goes wrong in compiling.. because this works for me with example provided.
(0038515)
RPM (reporter)
2015-04-15 09:54

I'm happy to try whatever, but could you respond to my overall point? Looking at the macros, do you agree that if passed a relative path, the code will try to execute EXISTS on that relative path? If so, I believe it should be changed.

Here is the VERBOSE output:
-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonLibs: /opt/create/ptoolsrte/0.5.2alpha5/packages/Python-2.7.5/lib/libpython2.7.so (found version "2.7.5")
-- Found SWIG: /home/mcnally/kestrel/swig/swig-3.0.5/INST/bin/swig (found version "3.0.5")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mcnally/kestrel/swig/BUILD
/home/create/ptoolsrte/0.5.2alpha5/packages/cmake-3.2.1/bin/cmake -H/home/mcnally/kestrel/swig -B/home/mcnally/kestrel/swig/BUILD --check-build-system CMakeFiles/Makefile.cmake 0
/home/create/ptoolsrte/0.5.2alpha5/packages/cmake-3.2.1/bin/cmake -E cmake_progress_start /home/mcnally/kestrel/swig/BUILD/CMakeFiles /home/mcnally/kestrel/swig/BUILD/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/mcnally/kestrel/swig/BUILD'
make -f CMakeFiles/_example_swig.dir/build.make CMakeFiles/_example_swig.dir/depend
make[2]: Entering directory `/home/mcnally/kestrel/swig/BUILD'
/home/create/ptoolsrte/0.5.2alpha5/packages/cmake-3.2.1/bin/cmake -E cmake_progress_report /home/mcnally/kestrel/swig/BUILD/CMakeFiles 1
[ 50%] Swig source
/home/create/ptoolsrte/0.5.2alpha5/packages/cmake-3.2.1/bin/cmake -E make_directory /home/mcnally/kestrel/swig/BUILD
../swig-3.0.5/INST/bin/swig -python -outdir /home/mcnally/kestrel/swig/BUILD -I/home/mcnally/kestrel/swig -I/opt/create/ptoolsrte/0.5.2alpha5/packages/Python-2.7.5/include/python2.7 -o /home/mcnally/kestrel/swig/BUILD/examplePYTHON_wrap.c /home/mcnally/kestrel/swig/example.i
make[2]: *** [example.py] Error 1
make[2]: Leaving directory `/home/mcnally/kestrel/swig/BUILD'
make[1]: *** [CMakeFiles/_example_swig.dir/all] Error 2
make[1]: Leaving directory `/home/mcnally/kestrel/swig/BUILD'
(0038516)
RPM (reporter)
2015-04-15 10:05
edited on: 2015-04-15 10:07

Are you sure you are using the same CMakeLists.txt, with the absolute path and the property set() operations still commented out?

Could you insert the same three debug lines I did into your UseSWIG.cmake so we can at least know if we are getting differing behavior from the macros or from our compilation environment?

(0038519)
Brad King (manager)
2015-04-15 10:14

Re 0015508:0038515: We should certainly avoid passing a relative path to if(EXISTS). It will be easiest to fix for us if you can provide a patch implementing behavior that works for your test case.
(0038520)
Tuukka Pasanen (reporter)
2015-04-15 10:31
edited on: 2015-04-15 10:32

I uploaded patch that uses absolute path and should correct behaviour UseSWIG-bug0015508-1.patch so please test it..

(0038521)
RPM (reporter)
2015-04-15 10:31

Sure. Not sure of the form you would prefer, but I uploaded a patch and a version of UseSWIG.cmake with the patch applied.

The only change is to pass the absolute path (already available) to the SWIG_GET_EXTRA_OUTPUT_FILES macro. Please let me know if there is anything else I can do.
(0038522)
RPM (reporter)
2015-04-15 10:34

Tuukka, looks like we both uploaded essentially the same patch. Your version works fine. Thanks.
(0038523)
Tuukka Pasanen (reporter)
2015-04-15 10:34
edited on: 2015-04-15 10:35

Normally patches should be in -u (unified mode) it's just habit. Yes and the fix is the same :D but good this one get around.

(0038524)
RPM (reporter)
2015-04-15 10:37

Thanks, I'll remember to post unified diffs from now on. Haven't contributed much before so I'm still learning the ropes.
(0038525)
Brad King (manager)
2015-04-15 11:41

I've applied the patch from 0015508:0038520:

 UseSWIG: Fix module name detection with relative source file
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd7e31bc [^]

Thanks!
(0039777)
Robert Maynard (manager)
2015-11-02 09:13

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2015-04-09 23:49 RPM New Issue
2015-04-13 09:20 Tuukka Pasanen Note Added: 0038490
2015-04-13 09:47 RPM File Added: CMakeLists.txt
2015-04-13 09:48 RPM File Added: example.i
2015-04-13 09:48 RPM File Added: example.h
2015-04-13 09:48 RPM File Added: example.c
2015-04-13 09:53 RPM Note Added: 0038494
2015-04-13 09:53 RPM Note Edited: 0038494
2015-04-15 01:48 Tuukka Pasanen Note Added: 0038512
2015-04-15 02:03 Tuukka Pasanen Note Edited: 0038512
2015-04-15 02:21 Tuukka Pasanen Note Edited: 0038512
2015-04-15 08:22 RPM Note Added: 0038513
2015-04-15 09:42 Tuukka Pasanen Note Added: 0038514
2015-04-15 09:54 RPM Note Added: 0038515
2015-04-15 10:05 RPM Note Added: 0038516
2015-04-15 10:07 RPM Note Edited: 0038516
2015-04-15 10:14 Brad King Note Added: 0038519
2015-04-15 10:29 RPM File Added: UseSWIG.patch
2015-04-15 10:29 RPM File Added: UseSWIG.cmake
2015-04-15 10:30 Tuukka Pasanen File Added: UseSWIG-bug0015508-1.patch
2015-04-15 10:31 Tuukka Pasanen Note Added: 0038520
2015-04-15 10:31 RPM Note Added: 0038521
2015-04-15 10:32 Tuukka Pasanen Note Edited: 0038520
2015-04-15 10:32 Tuukka Pasanen Note Edited: 0038520
2015-04-15 10:34 RPM Note Added: 0038522
2015-04-15 10:34 Tuukka Pasanen Note Added: 0038523
2015-04-15 10:35 Tuukka Pasanen Note Edited: 0038523
2015-04-15 10:37 RPM Note Added: 0038524
2015-04-15 11:41 Brad King Note Added: 0038525
2015-04-15 11:41 Brad King Status new => resolved
2015-04-15 11:41 Brad King Resolution open => fixed
2015-04-15 11:41 Brad King Fixed in Version => CMake 3.3
2015-04-15 11:41 Brad King Target Version => CMake 3.3
2015-11-02 09:13 Robert Maynard Note Added: 0039777
2015-11-02 09:13 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team