On Thu, Dec 10, 2009 at 02:28:52PM -0800, Fernando Perez wrote:
and that's because for each one of these, I correctly configure ALL of these:
PATH: binary execution LD_LIBRARY_PATH: dynamic linker search path LIBRARY_PATH: static linking by gcc (like -L) CPATH: generic include path for gcc (like -I), used for all languages C_INCLUDE_PATH: C-specific include path, after CPATH CPLUS_INCLUDE_PATH: C++-specific include path, after CPATH PYTHONPATH: search path for python packages
I have an aversion to changing LD_LIBRARY_PATH, LIBRARY_PATH, C_INCLUDE_PATH, CPATH, and CPLUS_INCLUDE_PATH, because I believe it leads to non reproducibles builds or run-time. More importantly, having to pull these tricks often reveals non-compatible run-times, and thus impossibility to share code, eg to use system code in localy-installed packages[*]. Now, we are indeed in such a situation (because we have binary incompatibility between numpy 1.3 and numpy 1.4), and there is nothing I can do to avoid it. It just makes me very unhappy. I am confortable enough with a Linux build environment to pull tricks to get stuff to build and run most of the time. I do however consider it wrong to have to do so. I don't want to use these tricks systematicaly. I'd much rather trip on the incompatibilities, and report them as bugs or annoyances. Thanks for offering, though. Gaël [*] To give examples, I don't consider that I should have to build atlas to use scipy svn. I do it quite often because I get better performance, but it should not be necessary. Similarly, I want to be able to install Mayavi svn and use the system VTK, and the system VTK Python bindings. Matplotlib should be able to use pygtk from the system...