please reopen #236, or add the following chunk to SConstruct :
@@ -662,6 +664,7 @@
if not libItems:
libItems = glob(os.path.join(searchDir, 'lib/%s*.*' % search_lib))
incItems = glob(os.path.join(searchDir, 'include/boost*/'))
if len(libItems) >= 1 and len(incItems) >= 1:
BOOST_LIB_DIR = os.path.dirname(libItems)
BOOST_INCLUDE_DIR = incItems.rstrip('boost/')
glob() matching is not prioritized and there's no way to override this (in fact one would expect BOOST_* variables to override this behavior but AFAICT it does not).
The above patch at least reorder directories so that :
/usr/include/boost is selected as it becomes the first of the list.
(other directories are then listed in a numerically reversed order, higher versions first)
Sorry but I was unable to reopen or comment on #236
Can you explain in a bit more detail what directories you wish to be sorted after /usr/include/boost ? e.g. what was the problem you ran into and why would this solve it?
On gentoo, using 2 boost slots, the heuristic always selected boost 1.46 (for which I had no python bindings for python 2.7).
I was not able to override this behavior with BOOST_* variables and had to change the autodetection glob() this way.
Giving the priority to /usr/include/boost (even without using sort()) would give a sane default value as distributions which handle multiple versions of boost already provides methods to change this, eg on gentoo, eselect boost set is used to switch the destination of this symlink.
eselect boost set
what other paths were being considered? What boost version did it find initially, instead of 1.46?
/usr/include/boost -> boost-1_48/boost
I wanted 1.48 to be used, all three directories were in present incItems but /usr/include/boost-1_46 was always the first one in the list (probably due to python glob() function)
But I may have to study the scons script again to know if 1.48 is now selected through the /boost symlink itself or because of an hypothetical failure followed by a working boost-1_48/ fallback.