|
Boost-Build : |
From: Larry Evans (cppljevans_at_[hidden])
Date: 2005-09-16 10:30:23
On 09/15/2005 10:58 PM, Rob Stewart wrote:
[snip]
> The platform specifics are managed by declarations that specify
> OS[/compiler[/build]], where OS can be, for example, SOLARIS,
> LINUX, NT, XP, etc., plus the aliases UNIX and WIN. The idea is
> that you can specify things for all Solaris builds, all *nix/GCC
> builds, etc. The Perl script determines the platform on which the
> build is running, but the compiler and build (default or release)
> must be specified explicitly if the default isn't appropriate.
>
> So, the option mentioned above is declared like:
>
> [ALT_BUILD_LOCATION]
> UNIX=/some/path/of/interest
>
> That would set the intermediate and final output directories to
> be under /some/path/of/interest, but only for Solaris and Linux
> builds, regardless of compiler or build type.
>
> One can put output from different compilers in different
> locations, perhaps to conserve disk space:
>
> [ALT_BUILD_LOCATION]
> UNIX,GCC=/first/path
> SOLARIS,SUNPRO6=/second/path
>
> That means that a Solaris or Linux GCC build goes to /first/path,
> whereas a SunPro6 build on Solaris goes to /second/path.
I'm guessing that a disadvantage of this method of
"encoding 'relevant' build features in build directory"
is the same as that mentioned here:
http://article.gmane.org/gmane.comp.lib.boost.build/7463
at the quote:
That's an exceedingly simplistic view of what Boost.Build is doing.
IOW, the programmer shouldn't be bothered with having to figure out
what the 'relevant' build features are and then encode them
in the build directory name. This should be done by the build
system, IIUC the above quote correctly.
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