fix boost version detection #1187

drzraf opened this Issue Apr 23, 2012 · 4 comments


None yet

3 participants

drzraf commented Apr 23, 2012

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*/'))
+         incItems.sort(reverse=1)
         if len(libItems) >= 1 and len(incItems) >= 1:
             BOOST_LIB_DIR = os.path.dirname(libItems[0])
             BOOST_INCLUDE_DIR = incItems[0].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?

drzraf commented Apr 23, 2012

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.


what other paths were being considered? What boost version did it find initially, instead of 1.46?

drzraf commented Apr 23, 2012
/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.

@lightmare lightmare added the resolved? label Feb 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment