Re: Changed (wrong?) behavior with make/common.copy in master

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
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build