Boost logo

Boost-Build :

Subject: Re: [Boost-build] Documentation: make 64-bit address mode easier to find.
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2014-11-17 11:09:01


On Sun, Nov 16, 2014 at 8:55 PM, Michael Rolle <m_at_[hidden]> wrote:

> Hi,
>
> It took me a while to find this, but Google is my friend. I was building
> stuff on Windows and getting 32-bit object files, but I wanted 64-bit
> object files.
>
> I didn't see the address-model property listed in the Boost.Build
> documentation. I have since found it in the list of commonly used
> properties, along with variant, link, etc.
>
> My issue with the documentation is that when it suggests that I can build
> the Boost libraries by simply running 'b2' with no arguments, this is
> misleading. By default it doesn't build all the possible variations. It
> builds both debug and release, and both single and multi threaded, but it
> only builds static libraries with 32-bit address model. So I would like to
> see mention of the other common possibilities, even if it's in the If
> Something Goes Wrong section.
>

Building all the variations is prohibitive. We used to ry and do that and
we had users complain that building would both take way too long and take
up way too much disk space. In addition building some variants causes name
collisions. As they are rarely wanted together and hence we leave it up to
the user to decide which ones to build in those cases. And 32 vs 64 is one
of those cases. It used to be 32 was the obvious default on Windows. That
might not be the best default any longer :-)

Better still, I'd like for Boost.Build to select 64-bit model by default if
> it's being run on a 64-bit processor with a 64-bit operating system. Doing
> that would have saved me a couple hours of work.
>

That's likely possible. I don't know how we can check for that though.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail


Boost-Build 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