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

7 messages
Open this post in threaded view
|

 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 : darwin ; > > actions make_libsettings > { >     echo boo > "$(<[1])" > } > make bar.txt : : @make_libsettings : bin/foo 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.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.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.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  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 : darwin ; >> >> actions make_libsettings >> { >> echo boo > "$(<[1])" >> } >> make bar.txt : : @make_libsettings : bin/foo >> 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 >> > > I get different results if I comment out the second "make copied.txt" > alternative: >> common.copy bin\copied.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? > This change is intentional.  Boost.Build no longer includes path components that do not affect the build settings.  You can use 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
Open this post in threaded view
|

## Reducing output from compile actions

 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
Open this post in threaded view
|

 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 : darwin ; >>> >>> actions make_libsettings >>> { >>>      echo boo > "$(<[1])" >>> } >>> make bar.txt : : @make_libsettings : bin/foo >>> copied.txt ; > This change is intentional. Boost.Build no longer > includes path components that do not affect the > build settings. You can use 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 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  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 : darwin ; >>>> >>>> actions make_libsettings >>>> { >>>> echo boo > "$(<[1])" >>>> } >>>> make bar.txt : : @make_libsettings : bin/foo >>>> copied.txt ; >> This change is intentional.  >> > 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 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
 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 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 : copied.txt ; tests/Jamfile: run testfoo testfoo.cpp : input.txt : : ../src//foo ../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 : foo_o ; exe foo : foo_o : copied.txt ; Annoying, but better than [every single feature that can go in a build path]. But how can I do the same for testfoo? Is there a shortcut like all ? Or can that be implemented easily? Thanks, -Matt _______________________________________________ Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
 AMDG On 07/09/2018 07:39 AM, Chambers, Matthew via Boost-build wrote: > > OK, a more complete example: > >    src/Jamfile: > >    make copied.txt : others/others.txt : common.copy ; >    exe foo : foo.cpp : copied.txt ; > >    tests/Jamfile: >    run testfoo testfoo.cpp : input.txt : : ../src//foo > ../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 : foo_o ; >    exe foo : foo_o : copied.txt ; > > Annoying, but better than [every single feature that can go in > a build path]. But how can I do the same for testfoo? Is there a > shortcut like all ? Or can that be implemented easily? > There isn't a 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 :   @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