Daniel Russel wrote: ... > I suggest the configure options simply be > extra_lib_paths="a//b/lib c/d/lib" > extra_include_paths="a/b/include c/d/include" > python_path="a/b/lib/python-2.5/..." > which get parsed and prepended to the scon environment before any > tests are performed and get added to all build environments. (I am not > sure if space is the best delimiter, but that can be solved later, > perhaps by using python syntax "['a/b/include', 'c/d/include']").
There is already a perfectly good delimiter for paths. It is ':' on Unix systems and ';' on Windows. Using space obviously prevents filenames containing spaces from being used (obviously you cannot use : or ; with regular paths, but everybody is familiar with this restriction already, since no other tools would work either). The existing IMP scons paths use standard delimiters. I don't know which delimiters you use in your recent patch but there is no reason not to use the standard ones.
Otherwise, your patch sounds reasonable to me - except perhaps for the rpath stuff on non-Mac systems, which is rather controversial on Linux systems and will not work at all on Windows or many other Unixes - and I will commit it once a) the nightly builds are fixed and b) I have time to review it and check out the rpath stuff. (Unless others have comments, of course.)
> The cgal, boost, em, modeller etc arguments can then be removed and > configure can then simply test if it can build against modeller, em, > cgal, boost etc and not worry about making sure all the paths are > added in the right places.
I agree. Most of these tests could be boolean rather than "package" options. I guess they are modeled after the autoconf-style --with options where you can specify a path for such packages, but most people use package managers these days and so don't specify a path. Like you say, it leads to all sorts of problems when dynamic linking is used.
> Keren, Javi and I have all at various points been confused > and frustrated by imp picking up copies of libimp in the diva modeller > build when neither the imp config arguments nor the directory name (/ > diva1/home/modeller-SVN) gave us any clue that such could happen.
I'm not sure how your solution would avoid that since the Modeller run scripts obviously have to add the Modeller library directories to the dynamic library path (and just like IMP, they try to do that by prepending rather than appending). I generally recommend installing Modeller locally rather than using the build in /diva1 if you want to build with Modeller anyway.
Ben