swig language bindings need to be updated to the same version as swig

[ryandesign (Ryan Carsten Schmidt)]

The swig 2.0.2 update has caused py26-pynifti to fail to install because swig-python was not also updated to 2.0.2:

--->  Building py26-pynifti
DEBUG: build phase started at Wed Feb 23 16:51:45 CST 2011
DEBUG: Executing proc-pre-org.macports.build-build-0
DEBUG: Executing org.macports.build (py26-pynifti)
DEBUG: Environment: CFLAGS='-m64' CXXFLAGS='-m64' CPATH='/opt/local/include' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.6' CCFLAGS='-I/opt/local/include -L/opt/local/lib -I/opt/local/include/nifti' F90FLAGS='-m64' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_rschmidt_macports_dports_python_py26-pynifti/work/.CC_PRINT_OPTIONS' LDFLAGS='' FCFLAGS='-m64' OBJCFLAGS='-m64' FFLAGS='-m64' CC_PRINT_OPTIONS='YES'
DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_python_py26-pynifti/work/pynifti-0.20090303.1" && /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 setup.py --no-user-cfg build'
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands --compiler options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options
running build_src
build_src
building extension "nifti._clib" sources
creating build
creating build/src.macosx-10.6-x86_64-2.6
creating build/src.macosx-10.6-x86_64-2.6/nifti
swig: nifti/clib.i
swig -python -I/opt/local/include/nifti -o build/src.macosx-10.6-x86_64-2.6/nifti/clib_wrap.c -outdir build/src.macosx-10.6-x86_64-2.6/nifti nifti/clib.i
:3: Error: Unable to find 'python.swg'
nifti/clib.i:259: Error: Unable to find 'typemaps.i'
Language subdirectory: python
Search paths:
   ./
   /opt/local/include/nifti/
   ./swig_lib/python/
   /opt/local/share/swig/2.0.2/python/
   ./swig_lib/
   /opt/local/share/swig/2.0.2/
Preprocessing...
error: command 'swig' failed with exit status 1
shell command " cd "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_python_py26-pynifti/work/pynifti-0.20090303.1" && /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 setup.py --no-user-cfg build " returned error 1
Error: Target org.macports.build returned: shell command failed (see log for details)

python.swg is in fact in /opt/local/share/swig/2.0.1/python/python.swg. All swig language binding ports must be updated to a new version when swig itself is updated. A note was added to the swig port in r72490 that was supposed to remind us of this fact.

[wmiler@…]

Cc Me!

[razzo1987@…]

Cc Me!

[lkraider (Paul Eipper)]

Cc Me!

[lkraider (Paul Eipper)]

Breaks graphviz build too:

:info:build swig -c++ -python -o gv_python.cpp ./gv.i
:info:build :3: Error: Unable to find 'python.swg'
:info:build make[4]: *** [gv_python.cpp] Error 1
:info:build shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_graphviz/work/graphviz-2.26.3" && /usr/bin/make -j2 all " returned error 2

[ryandesign (Ryan Carsten Schmidt)]

Yup, I'm sure it breaks everything that uses the swig language bindings.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #28540.

[macports@…]

Ahh true, simply changing the version line on ports/devel/swig-python/Portfile to 2.0.2 and copying the swig Portfile checksums to the language binding makes it work and libplist is compiling nicely.

Thanks

[ryandesign (Ryan Carsten Schmidt)]

r76501

[apinstein@…]

I ran into this bug today. Took me a few hours to figure out what happened.

Not sure if this is worth trying, but I wonder if you can re-architect the packages so that bindings would go in swig/2.x/ instead of the literal swig/2.0.2. That way this wouldn't be needed each time, and you'd only have to bump some version number if there was a BC-breaking change.

I have *no* internal knowledge of how swig works so it's possible that this is a stupid suggestion, but thought I'd mention it. The php5 package seems to use some "extension" system that seems to allow them to vary some information independently from the extension package; this makes it easier to update the core package without having to "touch" every single extension, and is thus a bit less fragile from a maintenance perspective.

Just a though.

[ryandesign (Ryan Carsten Schmidt)]

The swig and php5 packages are in identical situations. The swig language bindings need to be updated to the same version as swig when the swig version number increases, just as the bundled php5 extensions need to have their versions updated to the same version as php5 when its version increases. This is simply one of the responsibilities of maintaining swig and php5.

I would hesitate to second-guess the developers of swig about how their software works by changing their paths. Presumably there is a good reason why the full version number is used.

[sutasu@…]

With all latest updates it is still broken for swig 2.0.4.

cmake output:

-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- 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
-- Boost version: 1.47.0
-- Found the following Boost libraries:
--   system
--   date_time
--   filesystem
--   thread
--   regex
--   program_options
-- Found SWIG: /opt/local/bin/swig (found version "2.0.4")
-- Found PythonLibs: /opt/local/lib/libpython2.7.dylib 
-- Found JNI: -framework JavaVM 
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/stas/Projects/g/build

cmake build log fragment:
[ 29%] Swig source
cd /Users/stas/Projects/g/build/client/gpcomm/bindings/python && /opt/local/bin/swig -python -outdir /Users/stas/Projects/g/build/client/gpcomm/bindings/python -c++ -I/Users/stas/Projects/g/boost_extension -I/Users/stas/Projects/g/gpcommd -I/opt/local/include -I/System/Library/Frameworks/Python.framework/Headers -I/Users/stas/Projects/g/client/gpcomm/bindings/python -I/Users/stas/Projects/g/client/gpcomm/bindings/python/../.. -o /Users/stas/Projects/g/build/client/gpcomm/bindings/python/../../gpcommPYTHON_wrap.cxx /Users/stas/Projects/g/client/gpcomm/bindings/python/../../gpcomm.i
:3: Error: Unable to find 'python.swg'
/Users/stas/Projects/g/client/gpcomm/bindings/python/../../gpcomm.i:2: Error: Unable to find 'std_string.i'
/Users/stas/Projects/g/client/gpcomm/bindings/python/../../gpcomm.i:3: Error: Unable to find 'boost_shared_ptr.i'
make[2]: *** [client/gpcomm/bindings/python/../../gpcommPYTHON_wrap.cxx] Error 1
make[1]: *** [client/gpcomm/bindings/python/CMakeFiles/_gpcomm.dir/all] Error 2

[sutasu@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

sutasu, please remember to use WikiFormatting and to preview before submitting. But note that this ticket is about problems that occur when swig is updated but its language bindings ports aren't. That problem was resolved 6 months ago and this ticket was closed as fixed. If you are now experiencing a new issue, please file a new ticket.