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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Boost - Build mailing list
On master (c3dc95d3ac0219a0f774e6d382ed91d290cbde80) the behavior of my old make/copy targets has broken. With this simple Jamroot:
> make copied.txt : others/others.txt : common.copy ;
> make copied.txt : darwin/darwin.txt : common.copy : <toolset>darwin ;
>
> actions make_libsettings
> {
>     echo boo > "$(<[1])"
> }
> make bar.txt : : @make_libsettings : <location>bin/foo <dependency>copied.txt ;

Here is the output of running b2 with -n.

> common.mkdir bin\msvc-14.1
>         if not exist "bin\msvc-14.1\\" mkdir "bin\msvc-14.1"
>
> common.copy bin\msvc-14.1\copied.txt
>     copy /b "others\others.txt" + this-file-does-not-exist-A698EE7806899E69 "bin\msvc-14.1\copied.txt"
>
> common.mkdir bin\foo
>         if not exist "bin\foo\\" mkdir "bin\foo"
>
> Jamfile<C:\copytest>.make_libsettings bin\foo\bar.txt
>     echo boo > "bin\foo\bar.txt"

I get different results if I comment out the second "make copied.txt" alternative:
> common.copy bin\copied.txt
>     copy /b "others\others.txt" + this-file-does-not-exist-A698EE7806899E69 "bin\copied.txt"
>
> common.mkdir bin\foo
>         if not exist "bin\foo\\" mkdir "bin\foo"
>
> Jamfile<C:\copytest>.make_libsettings bin\foo\bar.txt
>     echo boo > "bin\foo\bar.txt"

Here is the result from my older checkout (sometime in late 2017, not sure of the exact commit):

> common.mkdir bin\msvc-14.1
>         if not exist "bin\msvc-14.1\\" mkdir "bin\msvc-14.1"
>
> common.mkdir bin\msvc-14.1\debug
>         if not exist "bin\msvc-14.1\debug\\" mkdir "bin\msvc-14.1\debug"
>
> common.mkdir bin\msvc-14.1\debug\threading-multi
>         if not exist "bin\msvc-14.1\debug\threading-multi\\" mkdir "bin\msvc-14.1\debug\threading-multi"
>
> common.copy bin\msvc-14.1\debug\threading-multi\copied.txt
>     copy /b "others\others.txt" + this-file-does-not-exist-A698EE7806899E69 "bin\msvc-14.1\debug\threading-multi\copied.txt"
>
> common.mkdir bin\foo
>         if not exist "bin\foo\\" mkdir "bin\foo"
>
> Jamfile<C:\copytest>.make_libsettings bin\foo\bar.txt
>     echo boo > "bin\foo\bar.txt"
The result is the same regardless of whether the second "make copied.txt" alternative is commented out or not. My code expects the make
targets to be copied to the full target path of the dependent targets. Is this change intentional?

Thanks,
-Matt
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

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

Boost - Build mailing list
AMDG

On 06/08/2018 01:12 PM, Chambers, Matthew via Boost-build wrote:

> On master (c3dc95d3ac0219a0f774e6d382ed91d290cbde80) the behavior of my
> old make/copy targets has broken. With this simple Jamroot:
>> make copied.txt : others/others.txt : common.copy ;
>> make copied.txt : darwin/darwin.txt : common.copy : <toolset>darwin ;
>>
>> actions make_libsettings
>> {
>>     echo boo > "$(<[1])"
>> }
>> make bar.txt : : @make_libsettings : <location>bin/foo
>> <dependency>copied.txt ;
>
> Here is the output of running b2 with -n.
>> common.mkdir bin\msvc-14.1
>>         if not exist "bin\msvc-14.1\\" mkdir "bin\msvc-14.1"
>>
>> common.copy bin\msvc-14.1\copied.txt
>> <snip>
>
> I get different results if I comment out the second "make copied.txt"
> alternative:
>> common.copy bin\copied.txt
>> <snip>
> The result is the same regardless of whether the second "make
> copied.txt" alternative is commented out or not. My code expects the
> make targets to be copied to the full target path of the dependent
> targets. Is this change intentional?
>

This change is intentional.  Boost.Build no longer
includes path components that do not affect the
build settings.  You can use <relevant>toolset
to force Boost.Build to include the toolset in
the path.  It will also work if you make copied.txt
depend on any compilation target.

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Reducing output from compile actions

Boost - Build mailing list
Instead of:

> compile-c-c++ C:\build-dir\msvc-14.1\rls\adrs-mdl-64\async-excpt-on\lnk-sttc\thrd-mlt\file.obj
> file.cpp

How can I make it just:
> compile-c-c++ C:\build-dir\msvc-14.1\rls\adrs-mdl-64\async-excpt-on\lnk-sttc\thrd-mlt\file.obj

And how could I do the same for common.copy? Instead of:
> common.copy C:\build-dir\msvc-14.1\rls\adrs-mdl-64\async-excpt-on\lnk-sttc\thrd-mlt\some.dll
> build-dir\some.file
>         1 file(s) copied.

Just:
> common.copy C:\build-dir\msvc-14.1\rls\adrs-mdl-64\async-excpt-on\lnk-sttc\thrd-mlt\some.dll

This would eliminate about 2 out of every 3 lines in my build logs.

Thanks,
-Matt
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

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

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
On 6/8/2018 11:36 PM, Steven Watanabe via Boost-build wrote:

> On 06/08/2018 01:12 PM, Chambers, Matthew via Boost-build wrote:
>> On master (c3dc95d3ac0219a0f774e6d382ed91d290cbde80) the behavior of my
>> old make/copy targets has broken. With this simple Jamroot:
>>> make copied.txt : others/others.txt : common.copy ;
>>> make copied.txt : darwin/darwin.txt : common.copy : <toolset>darwin ;
>>>
>>> actions make_libsettings
>>> {
>>>      echo boo > "$(<[1])"
>>> }
>>> make bar.txt : : @make_libsettings : <location>bin/foo
>>> <dependency>copied.txt ;
> This change is intentional.  Boost.Build no longer
> includes path components that do not affect the
> build settings.  You can use <relevant>toolset
> to force Boost.Build to include the toolset in
> the path.  It will also work if you make copied.txt
> depend on any compilation target.
>
Thanks for the quick answer Steven. There's aspect of the old behavior I haven't been able to reproduce:

If I make a target depend on copied.txt from a different project (directory), how do I get the copied.txt's <location> to be based on the
dependent target rather than the path components of the project that copied.txt is defined in?

Thanks,
-Matt
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

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

Boost - Build mailing list
AMDG

On 07/06/2018 04:22 PM, Chambers, Matthew via Boost-build wrote:

> On 6/8/2018 11:36 PM, Steven Watanabe via Boost-build wrote:
>> On 06/08/2018 01:12 PM, Chambers, Matthew via Boost-build wrote:
>>> On master (c3dc95d3ac0219a0f774e6d382ed91d290cbde80) the behavior of my
>>> old make/copy targets has broken. With this simple Jamroot:
>>>> make copied.txt : others/others.txt : common.copy ;
>>>> make copied.txt : darwin/darwin.txt : common.copy : <toolset>darwin ;
>>>>
>>>> actions make_libsettings
>>>> {
>>>>      echo boo > "$(<[1])"
>>>> }
>>>> make bar.txt : : @make_libsettings : <location>bin/foo
>>>> <dependency>copied.txt ;
>> This change is intentional.  <snip>
>>
> Thanks for the quick answer Steven. There's aspect of the old behavior I
> haven't been able to reproduce:
>
> If I make a target depend on copied.txt from a different project
> (directory), how do I get the copied.txt's <location> to be based on the
> dependent target rather than the path components of the project that
> copied.txt is defined in?
>

  I'm not sure I understand what you're trying to do
here.  I realize that sometimes files may need to be
in the same directory, but if the dependent target is
in a different project, then that automatically means
that you get different build directories.

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

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

Boost - Build mailing list


On 7/7/2018 12:17 AM, Steven Watanabe via Boost-build wrote:
Thanks for the quick answer Steven. There's aspect of the old behavior I
haven't been able to reproduce:

If I make a target depend on copied.txt from a different project
(directory), how do I get the copied.txt's <location> to be based on the
dependent target rather than the path components of the project that
copied.txt is defined in?

  I'm not sure I understand what you're trying to do
here.  I realize that sometimes files may need to be
in the same directory, but if the dependent target is
in a different project, then that automatically means
that you get different build directories.

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. 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?

Thanks,
-Matt

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

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

Boost - Build mailing list
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