Boost logo

Boost-Build :

Subject: Re: [Boost-build] build variant output directory
From: Phillip Seaver (phil_at_[hidden])
Date: 2008-10-07 10:55:08


Sebastian Hauer wrote:
> Hello,
> I was just wondering if there is some way of defining a variant's
> build output directory. The current build output directory nesting is
> just to deep for my project. Since I only have one debug variant and
> one release variant having a simple build output directory like:
>
> bin/debug
> bin/release
>
> would completely suffice. But instead boost build insists on storing
> everything in directories based on the selected feature set:
>
> bin\msvc-8.0\debug\threading-multi
> bin\msvc-8.0\release\debug-symbols-on\threading-multi
>
> Also notice the additional debug-symbols-on in the release build path
> since I selected to enable debug symbols for release builds.
>
> Regards,
> Sebastian
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
>

Things like that are the reason Boost.Build does such a long path. :-)
Debug symbols vs none isn't so bad, but linking single- and
multi-threaded code could cause serious problems.

That said, you should be able to do what you want with something like this:

exe foo : foo.c ;

install bin
    : foo
    : <variant>release,<debug-symbols>off:<location>bin/release
      <variant>release,<debug-symbols>on:<location>bin/symbols
      <variant>debug:<location>bin/debug
;

The "bin" argument just has to be a unique target name within this
jamfile as far as I know. "foo" should be replaced with the name of
your executable -- you should also be able to handle more than one
executable by separating the target names with spaces, like "foo bar".

I don't recall off the top of my head if the ",<debug-symbols>off" is
necessary. You should be able to test it with "bjam -n debug release
release/debug-symbols=on" (add a "-d1" argument if you don't want to see
all the compile commands).

Phillip


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