Re: [boost] Fwd: [1.34.0] Volunteers needed to check tarballs
On Thursday 26 April 2007 02:07, Thomas Witt wrote:
Vladimir,
Any idea what's going on here? See Jeff's report at the bottom for the problem.
Begin forwarded message:
From: Jeff Garland <jeff@crystalclearsoftware.com> Date: April 25, 2007 2:17:19 PM PDT To: Thomas Witt <witt@acm.org> Subject: Re: [boost] [1.34.0] Volunteers needed to check tarballs
On the downside, I'm unable to compile, but frankly this isn't a new problem for me on the particular machine -- I have the problem with the RC too. No doubt it's some kind of 'pilot error' on my part...lack of understanding of some new magical v2 process I need to follow (yes, I've read Dave's new getting started). The compile command from bjam basically spits out this:
bjam --toolset=gcc
-ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC - pthread ....
meaning it's missing the 'g++-4.0' part of the command. In my user- config.jam file I have:
using gcc : 4.0 : g++-4.0 ;
but it doesn't seem to do anything.
I have those possibilities: 1. Some wrong Boost.Build is used. Can you add --debug-configuration option to bjam and see where Boost.Build files are being loaded from? 2. Auto-configuration does not like pre-configured version in user-config.jam. Can you try bjam gcc-4.0 3. There's no actually g++-4.0 binary in PATH. Can you check that? If you fail to fix the problem still, please send me the output of --debug-configuration. - Volodya
Vladimir Prus wrote:
On Thursday 26 April 2007 02:07, Thomas Witt wrote:
Vladimir,
If you fail to fix the problem still, please send me the output of --debug-configuration.
Thx for the assist -- the debug-configuration helped me figure it out. The problem was a user-config.jam in my home directory that wasn't up to date. 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. Jeff
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. Just my 2ct. Thomas
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 don't have a problem with being able to configure it somewhere outside the tree, it should just be explicit. The likelihood that my home directory is the 'best answer' is extremely low if I'm working on anything more than a solo project. So picking that 'first' is very surprising...at least to me. Jeff
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 Regards, m
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
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. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Apr 26, 2007, at 1:43 PM, 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
FWIW, I totally agree
Me too. We've had dozens of users hit this same problem (finding the user-config.jam in their home directory and ignoring the one in their project). Let me add my voice to this proposed change. -- Noel Belcourt
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
participants (6)
-
Jeff Garland -
K. Noel Belcourt -
Martin Wille -
Stefan Seefeld -
Thomas Witt -
Vladimir Prus