|
Boost-Build : |
Subject: Re: [Boost-build] Changed (wrong?) behavior with make/common.copy in master
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-07-11 15:18:34
AMDG
On 07/09/2018 07:39 AM, Chambers, Matthew via Boost-build wrote:
> <snip>
> OK, a more complete example:
>
> Â Â src/Jamfile:
>
> Â Â make copied.txt : others/others.txt : common.copy ;
> Â Â exe foo : foo.cpp : <dependency>copied.txt ;
>
> Â Â tests/Jamfile:
> Â Â run testfoo testfoo.cpp : input.txt : : <dependency>../src//foo
> <dependency>../src//copied ;
>
> Suppose in order for foo and testfoo to run, they need to have
> copied.txt in the same directory as the executable.
As written, testfoo wouldn't have worked before either.
- in `testfoo testfoo.cpp`, testfoo is not defined and
I can't guess what it's supposed to be. If testfoo is
an executable, then adding testfoo.cpp doesn't make sense.
> For foo, I can do
> that by making it depend on a compiled target, like:
>
> Â Â src/Jamfile:
> Â Â obj foo_o : foo.cpp ;
> Â Â make copied.txt : others/others.txt : common.copy : <dependency>foo_o ;
> Â Â exe foo : foo_o : <dependency>copied.txt ;
>
> Annoying, but better than <relevant>[every single feature that can go in
> a build path]. But how can I do the same for testfoo? Is there a
> shortcut like <relevant>all ? Or can that be implemented easily?
>
There isn't a <relevant>all, but it's not too hard to implement.
As a temporary workaround, you can pass --ignore-relevance on
the command line (which restores the old behavior globally).
I'm still considering the best way to handle this kind of case.
Here's one idea:
generate foo : others/others.txt foo.exe :
<generating-rule>@copy-files-into-one-directory ;
rule copy-files-into-one-directory (
project id ? : sources + : property-set )
{
# determine the build directory from the property-set
# For each source,
# if it is already in the correct directory, return it unchanged
# otherwise make a copy
}
In Christ,
Steven Watanabe
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