Re: [Boost-build] common.copy target location

Subject: Re: [Boost-build] common.copy target location
From: Ian Emmons (ian_at_[hidden])
Date: 2018-08-30 10:39:48

On Aug 28, 2018, at 9:31 AM, Steven Watanabe via Boost-build <boost-build_at_[hidden]> wrote:

> AMDG
> 
> On 08/28/2018 06:01 AM, Ian Emmons via Boost-build wrote:
>> I am using Boost 1.67.0, and I just recently discovered a change in its
>> behavior compared to previous versions.  I am running unit tests, and
>> these tests require a copy of a configuration file in the same directory
>> as the running executable.  To make that work, I added an explicit
>> dependency to the unit-test target and an explicit target performs the
>> copy, like so:
>> 
>>     unit-test ParliamentTest
>>         :    [ glob $(SourceDir)/*.cpp ]
>>             list-of-libraries
>>         :    <target-os>windows:<dependency>ParliamentConfig.txt
>>         :    # default build
>>         :    # usage requirements
>>         ;
>> 
>>     explicit ParliamentConfig.txt ;
>>     make ParliamentConfig.txt : $(SourceDir)/ParliamentConfig.txt :
>> @common.copy ;
>> 
>> In prior versions of Boost.Build, the copy would land in the same
>> directory as the test executable, e.g.,
>> "<output-dir>/msvc-14.1/release/address-model-64/threading-multi/ParliamentConfig.txt",
>> but in Boost 1.67.0 the copy lands in "<output-dir>".
>> 
>> Is this change expected?  How can I get back to the old behavior?
>> 
> 
>  The change is intentional.  The directory for a target
> only includes features that affect the building of the
> target in some way.  common.copy doesn't depend on any
> features, so the target is placed in the root output
> directory.
> 
> You have two choices to work around this.  Adding
> <relevant>toolset <relevant>variant <relevant>address-model,
> etc, will explicitly force Boost.Build to include
> these features in the path.  The other option is
> to refactor it so that the config file depends on
> the executable (and thus inherits feature relevance).
> 
> exe ParlimentTest.exe : ... ;
> make ParlimentConfig.txt : ... : ... : <use>ParlimentTest.exe ;
> unit-test ParlimentTest : ParlimentTest.exe :
>  <target-os>windows:<dependency>ParlimentConfig.txt ;
> 
> See
> https://boostorg.github.io/build/manual/develop/index.html#bbv2.builtin.features.relevant
> for more details.  (This was supposed to be linked
> from here:
> https://boostorg.github.io/build/manual/develop/index.html#bbv2.reference.buildprocess.targetpath
> but the link seems to have been lost in the
> move to asciidoc.)
> 
> In Christ,
> Steven Watanabe

Thanks much for your help.  One follow-up:  I'm having trouble understanding the correct syntax for adding <relevant>.  Where in the make statement does this go?  The only syntax accepted by b2 that I've found so far is this:

make ParliamentConfig.txt
   : $(SourceDir)/ParliamentConfig.txt
   : @common.copy
     <relevant>toolset <relevant>variant ...
   ;

but that has no effect, i.e., the results are unchanged.  (I don't see the make command in the reference, so I'm having trouble understanding where these features properly fit in.)

I will try refactoring the dependency order today to see if that works, but I prefer using <relevant> if possible because then the code says exactly what I'm trying to do.

Thanks,

Ian