Re: common.copy target location

Ian Emmons via Boost-build <[email protected]>
Newsgroups gmane.comp.lib.boost.build
Message-ID <[email protected]>

On Aug 28, 2018, at 9:31 AM, Steven Watanabe via Boost-build <[email protected]> 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
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.