From: Deane Yang (deane_yang_at_[hidden])
Date: 2006-01-06 22:12:41
Daryle Walker wrote:
> I followed the second link to create a bjam file. It put it in a
> "bin.macosxppc" sub-directory, and I copied the "bjam" inside to "~/bin"
> which is in my $PATH.
> How do I activate the clean target? Neither "sh ./build.sh clean" nor "sh
> /build.sh darwin clean" worked. I want to do this so later CVS updates
> won't detect the building files (and report them as unregistered).
> Will this script always create a "bjam" file blindly, or will it do
> dependency checking and only build as necessary? I need some way to do the
This is a good question that I'll leave to the experts. In particular,
is it a bad idea to have a Jamfile or Jamfile.v2 (or both) in the
jam_src directory that includes a clean target? This would allow you to
rebuild using bjam itself.
>> In particular, I recommend downloading the latest from the CVS
>> repository and building bjam from scratch. Do "bjam --version" to test
>> whether you've got things set up OK.
> I don't think it's OK. After changing my "~/.profile" to remove the
> BOOST_BUILD_PATH export (and resetting), I ran the command from the
> "jam_src" directory, getting:
> (description of errors from doing "bjam --version" deleted)
Yes, you're right! I never noticed that this only works under certain
circumstances. Here's what seems to work for me: Go to the directory
that contains the boost-build.jam file (which in turn contains the
relative path to boost/tools/build/v2 directory) and run "bjam
--version" there. That seems to work for me (but I get the same errors
you got when I do the same things you did).
> However, when I tried Boost.Build v2 from the "jam_src" directory, I got a
> processing delay and then [errors ensue]
You need to have a proper v2 Jamfile in a directory to run "bjam --v2".
The jam_src directory does not. A better idea is to test "bjam --v2" in
boost/tools/build/v2/example/hello (after you've edited user-config.jam;
if you have VC++ of any recent version installed in a standard
location, just put "using msvc : all ;"; if you have gcc in your path,
then just use "using gcc ;"). If that works, then try bjam in the
directory boost/tools/quickbook. Finally, you can try running it in
boost/doc (which won't work unless you have all of the tools properly
installed; this is yet another challenge).
> I don't want to try this with the "darwin" toolset until I know more about
> what's happening. Anyway, I'm trying out Boost.Build to do that
> documentation demonstration, I do _not_ want to build actual libraries or
> install any headers or libraries. (I believe in adding headers and source
> code to my project file, so I never have to worry about mismatched compiler
> settings. Can you even mix Boost.Build material with Xcode?)
Which documentation demonstration?
> I think Mac OS X 10.4 comes with both Python and ICU. How would I tell
> Boost.Build to use the appropriate system library files?
Best left for MacOSX experts, but read the documentation, too. If gcc
can't find the libraries automatically, it is easy---no, **very**
easy---to insert the appropriate OS-dependent directives in your Jamfile.
I have to say that the difficulty in initially setting up Boost Build v2
makes it appear to be an "experts-only" tool, but in fact it is in many
ways a great tool for non-experts like me. It has and hides a lot of
"implementation details" of how to compile and link software on
different platforms. Even if you compile on only one platform (like
Windows), it's easier to use than any alternative I know of (because you
don't even have to know about vcvars.bat or set any environment
variables). I now use the Visual Studio IDE only for debugging; bjam is
**much** easier to use than even the IDE. And I've been able to compile
and link my software on Windows, Linux, Solaris, and MacOS X using the
exact same set of files, including the exact same Jamfiles, by just
typing "bjam" each time. Try doing that with Makefiles (just figuring
out the right linker command and options is a complete nightmare).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk