From: David Abrahams (abrahams_at_[hidden])
Date: 2001-06-04 16:20:20
----- Original Message -----
> Well then, let me jump in with some questions and comments.
> I wrote a jamfile for Boost.Threads with very little effort, which
> was very promising! A Win32 static library for MSVC is properly
> generated by my Jamfile which is great. I've also got GCC installed
> on the system, however, and this is still not working. I'll track
> down why shortly, but this has lead to a question... how does one go
> about building for a single compiler? By default all compilers are
> attempted which generates a lot of static which makes it harder to
> focus on the problems with a single compiler set.
build with gcc:
jam -f<...>allyourbase.jam -sTOOLS=gcc
build with msvc and gcc:
jam -f<...>allyourbase.jam -sTOOLS="msvc gcc"
always build with msvc:
make the release build:
jam -f<...>allyourbase.jam -sBUILD=release
make debug and release:
jam -f<...>allyourbase.jam -sBUILD="debug release"
> Also, I did run into problems with Jam and long file names. For
> Win32 the Boost.Threads library relies on the Platform SDK so I've
> got an include line in the jamfile like this:
> <include>"c:/program files/microsoft platform sdk/include"
> With or with out the quotes this fails as Jam breaks the path at any
> space character. So, once again I had to resort to short file names
> like so:
> Hopefully we can get the Jam developers to correct this one soon :(.
This may well be just a shortcoming in my Jam code. I'll try expanding the
sample project to include a pathname with a space.
> Another thing I had to do was copy all the .JAM files and the
> JAMRULES file from the build_system_2001_6_3 directory into my own
> root directory. For now this is no big deal, but what's going to be
> the proper way to get this to work?
The docs describe the TOOLSET_DIR variable:
Toolset descriptions are located in the project's root directory, or a
directory specified by TOOLSET_DIR
boost-base.jam, until it is merged into allyourbase.jam, has a similar
variable, BOOST_BASE_DIR, with a similar meaning. I'm open to other
> General first impressions are very good :). This should make
> developing build scripts for the Boost libraries very trivial in
> comparison to Make scripts or other alternatives!
I sure hope so; That's the goal.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk