Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2003-11-20 08:45:44


> >There are also two "The system cannot find the file specified" messages
in
> >the body of the log information. Both date-time library related.
>
> I've been running stage builds for a while now and I haven't seen that
> (trying another one now). So it's something new in date-time.

No it's a Windows'ism: date_time dlls don't export anything, so no import
lib gets generated, so come install/stage time the it can't be found.
Basically the date_time Jamfile needs fixing.

Likewise we need to add <runtime-link>dynamic as a requirement to some of
the dll builds.

> >* The bjam run produced only mt and mt-gd library variants. It would be
> >preferable if it produced the set of variants that is usual for the
> >particular compiler. For example, VC++ users often use static linking,
and
> >that is the default for that compiler/linker. getting_started.html didn't
> >seem to even mention how to instruct bjam to produce other variants.
>
> Yes it would be preferable, but not sure if it's possible. I can certainly
> put code in there that given the toolsets they specified sets the variants
> to build. But the problem is that there is only one set of variants, so if
> you specify more than one toolset the variants for one might not be what
you
> want for the others. Or we can make building the additional static
versions
> the default, but that's more compiling.
>
> As for docs, the best I could probably do is to point them to the relevant
> section in the Boost.Build docs about specifying variants, with a short
> intro before that.

Where is that: I recently tried to find it and couldn't :-(

Even so this is going to be a really common requirement for windows
compilers (there are 6 runtimes for vc for example, so we really need to
build with: -sBUILD="debug release <runtime-link>static/dynamic
<threading>multi/single", and that's darn hard to type by hand: can I also
direct you to: http://lists.boost.org/MailArchives/boost/msg54955.php while
we're on the subject?

> >* Wouldn't it be better to default --builddir= to someplace out of the
> >distribution tree?
>
> Any suggestions?
>
> For Windows we could probably default to C:\Boost\build, or something
such.
> But for unix I can't think of an easy outside default.

The system temp directory might be a good choice ?

John.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk