Boost logo

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