Subject: Re: [Boost-build] Output directories of Boost Build
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-09-20 04:26:07
Suppose one has exactly that same use case as you - sources on shared
folder. But, its not only Boost, but also an app using Boost. If I build
that app and specify --build-dir then I want build products of app and
Boost to be separate - in part because there might be naming conflicts
otherwise and in part so that building another app using Boost do not
rebuild Boost from scratch. These considerations do not apply when
build-dir is specified in Jamroot - because there, it is relative to source
directory and therefore disambiguated naturally.
Regarding tools that override build dir - that is bad, I'd be happy to help
On Sun, Sep 20, 2015, 04:45 Edward Diener <eldiener_at_[hidden]> wrote:
> On 9/19/2015 3:01 PM, Niklas Angare wrote:
> > "Edward Diener" <eldiener_at_[hidden]> wrote:
> >> Finally I notice a 'dist' sub-directory off of my Boost C++ root where
> >> a few tools, boostdep and inspect, have built their executables in
> >> './dist/bin'. Is this sub-directory relative to the --build-dir setting
> > Yeah, I find it disturbing that some parts of the build process creates
> > files among the source files.
> If this is being controlled by some option, like --build-dir, it does
> not bother me. But if it is occurring in some hard-coded subdirectory
> relative to the Boost C++ source then I think that this is bad.
> >> My goal is to move the Boost git repository to a common partition
> >> shared by multiple Windows OSs ( Vista, 7, 8.1, 10 ),
> > Does it matter if these build related files are shared between the
> > operating systems?
> Yes ! Build files created when using one version of Windows are not
> guaranteed to be correct or to execute on a different version of Windows.
> I want all build files to be created local to the OS I am using. Source
> files OTOH can be shared. That is the entire intention behind my OP.
> Unsubscribe & other changes:
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