Searching for boost-build.jam

[Edward Diener]

Upon invocation bjam should also look for boost-build.jam in the Boost tree specified by the --boost=/path/to/Boost option if it can not find it anywhere else in its normal search path.

This would allow any Boost-like library, using the directory structure suggested by the sandbox, to have its jamfiles execute properly even if it were not located within a Boost tree or beneath a top-level directory with its own boost-build.jam, as long as the bjam command had a --boost/path/to/Boost option pointing to a Boost distribution.

[Vladimir Prus]

I am not sure this is the right solution. I plan soonish, you'll have two options:

1. Install Boost.Build (either from a standalone package, installer, or Boost SVN checkout) to a system location, and then "bjam" will automagically find Boost.Build files, no setup required, or

2. You'd build bjam with "./boostrap.{bat,sh}" and then add Boost root to your PATH, and again, Boost.Build will be found automagically.

Will those options work for you?

[Edward Diener]

These are my comments about your two alternate solutions:

1) This would remove Boost Build's connection to a particular Boost distribution. Are you sure you want to install Boost Build separately from Boost ? Also, unless you have an installation program when you are distributing Boost Build separately, it is hard to understand how you will find Boost Build automagically from just an SVN checkout somewhere.

2) Adding Boost root to the PATH is horrible. Lots of people have multiple Boost installations. Changing the PATH ( or any environment variable ) with each new Boost distribution is definitely not the way to go.

I do not understand what is wrong with letting the end-user point to a Boost installation with the --boost=/path/to/Boost option and using that, as a last resort, to find Boost Build. It is obviously the most flexible way for the user of Boost Build and can not be that hard to program. Tying Boost Build to a single location, when end-users may have multiple Boost installations on their system and need to test some Boost library against any of them, does not seem the way to do things. Try to put yourself in the end-user's position rather than in your position as the primary Boost Build developer.

[Steven Watanabe]

Currently the situation is that bjam is separate and Boost.Build is tied to Boost. This doesn't really make sense, because bjam and Boost.Build are two halves of the same tool. Installing them as a single unit avoids the ugly search that we have right now.