
Stefan Seefeld wrote:
Martin Wille wrote:
Thomas Witt wrote:
In article <4630E0FB.4090905@crystalclearsoftware.com> Jeff Garland <jeff@crystalclearsoftware.com> wrote:
I think searching paths outside the boost tree for a user-config.jam without explicit user input and, in particular, choosing it ahead of one in that is in the local boost tree is a bug -- it violates the principle of least surprise. FWIW it's not that clear cut to me. You really want to be able to configure boost build in some central place without having to look for stuff that might interfere.
I think Jeff wants these priorities:
1. local (to the project) configuration files
2. user configuration
3. system configuration
Yeah, something like that, but still I prefer not searching around on my system without me requesting it. One day I might do an apt-get on some project that uses boost and then boost will show up in my /usr directory -- if it happens to have a user-config in it things might break. People with projects that have these files should have options to explicitly set the paths. Here's some thoughts: 1. local a) fail if not found, no external search by default b) don't fail, assume defaults With 1a you probably don't want to deliver a default one that's correctly named. Force everyone to at least rename it. 2. explicit option to add paths (it may have this now, I don't know) a) logical search paths --system --user b) explicit paths --config-dir=/usr/local/boost
FWIW, I totally agree (we did have a short discussion about this on IRC a while ago). In addition, I don't think the name 'user-config.jam' is very appropriate, especially as a file in $(HOME). It doesn't give any hint at being related to boost. There are thousands of 'user config' things in my home, but most in a project / application - specific subdirectory, to make it clear what they relate to.
I agree, completely. Something like: boost_1_34_0-toolset_config.jam would be better. That would prevent the next version from accidentally picking up one in my home directory from a year ago. Of course, adding the version in there might be controversial... Jeff