Hi Valery: On 2009-07-27 13:44+0900 Valery Pipin wrote:
>> On 2009-07-13 17:31+0900 Valery Pipin wrote: >>> Hi >>> >>> I had a problem to compile python module for plplot-5.9.4 on altlinux. >>> It was due to the nonstandard location of numpy headers. On my system >>> they are in /usr/include/numpy. It is possible to say to cmake to find >>> them there? >> >> Try using CMAKE_INCLUDE_PATH documented in >> http://www.cmake.org/Wiki/CMake_Useful_Variables. > It does not work. > The part of the spec file is > #################### > %build > mkdir alt > cd alt > > export CFLAGS="$RPM_OPT_FLAGS " > export CXXFLAGS="$RPM_OPT_FLAGS " > export FC="gfortran -O2" > cmake .. \ > -DCMAKE_INSTALL_PREFIX:PATH=/usr \ > -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \ > -DENABLE_octave=OFF \ > -DPLD_wxwidgets:BOOL=OFF \ > -DPL_FREETYPE_FONT_PATH:PATH="/usr/share/fonts/ttf/freefont" \ > -DCMAKE_INCLUDE_PATH="%_includedir:%_includedir/python2.5/:%_included > ir/numpy/" > > #################### > > It produces the corresponded diagnostic information during configure stage: > ......... > + CXXFLAGS='-pipe -Wall -O2 ' > + export 'FC=gfortran -O2' > + FC='gfortran -O2' > + cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr - > DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 -DENABLE_octave=OFF - > DPLD_wxwidgets:BOOL=OFF - > DPL_FREETYPE_FONT_PATH:PATH=/usr/share/fonts/ttf/freefont - > DCMAKE_INCLUDE_PATH=/usr/include:/usr/include/python2.5/:/usr/include/numpy/ > > ........... > > However, python wrapper is not able to find these headers > ............................ > [ 22%] Building C object > bindings/python/CMakeFiles/_plplotcmodule.dir/plplotcmodulePYTHON_wrap.c.o > cd /home/va/RPM/BUILD/plplot-5.9.4/alt/bindings/python && /usr/bin/gcc - > D_plplotcmodule_EXPORTS -DQT_DLL -DQT_SVG_LIB -DQT_GUI_LIB -DQT_CORE_LIB - > DHAVE_CONFIG_H -pipe -Wall -O2 -fPIC -I/usr/include/qt4 - > I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore - > I/home/va/RPM/BUILD/plplot-5.9.4/include - > I/home/va/RPM/BUILD/plplot-5.9.4/lib/qsastime - > I/home/va/RPM/BUILD/plplot-5.9.4/alt - > I/home/va/RPM/BUILD/plplot-5.9.4/alt/include - > I/home/va/RPM/BUILD/plplot-5.9.4/alt/bindings/python -I/usr/include/python2.5 > -I/usr/lib64/python2.5/site-packages/numpy/core/include/numpy - > I/home/va/RPM/BUILD/plplot-5.9.4/bindings/swig-support -o > CMakeFiles/_plplotcmodule.dir/plplotcmodulePYTHON_wrap.c.o -c > /home/va/RPM/BUILD/plplot-5.9.4/alt/bindings/python/plplotcmodulePYTHON_wrap.c > /home/va/RPM/BUILD/plplot-5.9.4/alt/bindings/python/plplotcmodulePYTHON_wrap.c:2711:33: > error: arrayobject.h: No such file or directory > /home/va/RPM/BUILD/plplot-5.9.4/alt/bindings/python/plplotcmodulePYTHON_wrap.c:3140: > error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token > .......................... > > I can compile if I make the soft links from /usr/include/numpy to > /usr/include/. > In the actual build fragment you showed to give context to the error message, I see no mention of -I/usr/include/numpy. So it appears that setting the cache variable with -DCMAKE_INCLUDE_PATH=/usr/include:/usr/include/python2.5/:/usr/include/numpy/ does not work (i.e., does not propagate to -I options) in this case. (Strangely, -I/usr/include/python2.5 does appear above but not -I/usr/include or -I/usr/include/numpy). Of course, using a -D option to set a cache variable is not exactly the same as using an environment variable so just as a test please try setting the environment variable instead: e.g., export \ CMAKE_INCLUDE_PATH=/usr/include:/usr/include/python2.5:/usr/include/numpy cmake ... Normally, the environment variable approach works fine for me. Note I have dropped the trailing slashes which _might_ make a difference. You may also want to try using different directory orders in the colon-separated list, drop /usr/include from the list (which should never be necessary), etc., but from my experience the environment variable approach should "just work". I have never actually tried the -D option way to set the CMAKE_INCLUDE_PATH cache variable. It is certainly mentioned in the documentation as an alternative to the environment variable approach, but since I have never tried it, and since it probably uses a quite different code path, there may be a bug in it, it may only work for single directories, trailing slashes may confuse it, etc. Let me know how it turns out. 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
