From: John Maddock (John_Maddock_at_[hidden])
Date: 2001-07-24 06:47:46
>Can it be done automatically? I'm not sure how David Turner feels about
>this, but FTJam is currently in the Perforce public depot, and he's been
>talking about an independent CVS host at SourceForge. The potential for
>things getting out of synch is not to be underestimated.
I know. I just want this as easy as possible for new users...
>"complete" pain? I agree that it's ugly, but it sounds like you're
>exaggerating a little bit. We're looking at alternatives (one involves
>compiling allyourbase.jam into Jam so you don't need the -f option), but
>the meantime I suggest you write yourself a little batch file or shell
>script that hides the need for the -f option.
Well that's exactly what I did, I think I could even write a shell install
script that automates the production of a wrapper that sets environment
options and adds the necessary -f option, even so "allyourbase.jam" is
really ugly name IMHO, sorry :-(
>Can you give me some idea what you mean by "step by step instructions for
>particular compilers"? Users shouldn't have to know much of anything about
>particular compilers to use the system. That's the goal, at least.
Sure but what options are available for particular compilers? what options
are available for all compilers? How do I insist that a build is
multi-threaded only? etc
>Because I'm not sure how best to organize things, yet. It isn't at all
>to me how people will want to use it. They may want to replace the toolset
>definitions while using the boost-supplied boost-base.jam, for example. I
>figure that with a little bit of use, some of these issues will become
OK, but I would still like an "idiots first user guide to setting things
up", I found it less than intuitive in the current docs, mainly because the
information I needed was scattered around a bit, or at least that's how it
felt at the time, maybe I was just in a rush :-)
>No, it's not. I checked in a fix for Bill's Jamfile last week. Did you try
>getting his stuff from the thread-inital branch?
No I got the zip, that may be the issue.
>Well, you need to add it to the requirements for the target. Requirements
>come in a section following the sources, and might look like this for your
That's what I figured but BOOST_RE_BUILD_DLL should not be defined for
static lib builds - your example sets it for all build options, yes?
>How you link to the runtime is independent of whether you're building a
>static or dynamic library, right?
Um OK, I think, I when I saw "dynamic" I thought it applied to the built
library, not the runtime, my mistake.
>The default build is debug only. You can change what's built by default
>any target by adding it to the default-build sectioni that follows the
> : debug release
>will build the debug /and/ release variants.
> : debug release <runtime-link>static/dynamic
>will build versions that link to the runtime both statically and
OK, is it possible to produce a static lib with a dynamic runtime using
- John Maddock
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk