Hi, everyone! Starting yesterday, I experienced failures on all my test builds. Their logs contain the following message: travis_time:end:1a83bdea:start=1545229245463720000,finish=1545229258317024000,duration=12853304000 [0Ktravis_fold:end:install.10 [0Ktravis_fold:start:install.11 [0Ktravis_time:start:04d79bf0 [0K$ ./b2 headers boost-install.jam: No such file or directory Jamroot:307: in boost-install ERROR: rule "boost-install.boost-install" unknown in module "Jamfile". libs/atomic/build/Jamfile.v2:38: in modules.load /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:372: in load-jamfile /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:64: in load /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:89: in load-used-projects /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:75: in load /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:142: in project.find /Users/travis/build/CromwellEnage/boost-root/tools/build/src/build-system.jam:618: in load /Users/travis/build/CromwellEnage/boost-root/tools/build/src/kernel/modules.jam:295: in import /Users/travis/build/CromwellEnage/boost-root/tools/build/src/kernel/bootstrap.jam:139: in boost-build /Users/travis/build/CromwellEnage/boost-root/boost-build.jam:17: in module scope travis_time:end:04d79bf0:start=1545229258327432000,finish=1545229259660893000,duration=1333461000 [0K [31;1mThe command "./b2 headers" failed and exited with 1 during . [0m It's also happening on Appveyor, and just from looking at < https://github.com/boostorg/graph/pull/144>, I'm not the only one who is encountering these errors. Any help would be appreciated. Thanks! Cromwell D. Enage
On 12/19/18 6:29 PM, Cromwell Enage via Boost wrote:
Hi, everyone!
Starting yesterday, I experienced failures on all my test builds. Their logs contain the following message:
travis_time:end:1a83bdea:start=1545229245463720000,finish=1545229258317024000,duration=12853304000 [0Ktravis_fold:end:install.10 [0Ktravis_fold:start:install.11 [0Ktravis_time:start:04d79bf0 [0K$ ./b2 headers
boost-install.jam: No such file or directory
Jamroot:307: in boost-install
ERROR: rule "boost-install.boost-install" unknown in module "Jamfile".
libs/atomic/build/Jamfile.v2:38: in modules.load
/Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:372: in load-jamfile
/Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:64: in load
/Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:89: in load-used-projects
/Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:75: in load
/Users/travis/build/CromwellEnage/boost-root/tools/build/src/build/project.jam:142: in project.find
/Users/travis/build/CromwellEnage/boost-root/tools/build/src/build-system.jam:618: in load
/Users/travis/build/CromwellEnage/boost-root/tools/build/src/kernel/modules.jam:295: in import
/Users/travis/build/CromwellEnage/boost-root/tools/build/src/kernel/bootstrap.jam:139: in boost-build
/Users/travis/build/CromwellEnage/boost-root/boost-build.jam:17: in module scope
travis_time:end:04d79bf0:start=1545229258327432000,finish=1545229259660893000,duration=1333461000 [0K [31;1mThe command "./b2 headers" failed and exited with 1 during . [0m
It's also happening on Appveyor, and just from looking at < https://github.com/boostorg/graph/pull/144>, I'm not the only one who is encountering these errors. Any help would be appreciated.
See Peter's announcement: Feature/cmake-config merged to develop; yml files need to be updated
It's also happening on Appveyor, and just from looking at < https://github.com/boostorg/graph/pull/144>, I'm not the only one who is encountering these errors. Any help would be appreciated.
See Peter's announcement: Feature/cmake-config merged to develop; yml files need to be updated
Ugh. Ok we can update those files, though I bet there are plenty of libraries that have authors not around here so much that will get caught by this for months to come. More of an issue, is that this breaks all the existing PR's against a library - if the library author spots this and fixes develop *and* the PR submitters can be persuaded to rebase on develop then we can get past that, but IMO that's a bit of a tall order. In the mean time quite a few libraries will have all new or updated PR's fail all CI tests which will be rather off-putting for submitters to say the least. At the very least someone should quickly survey all the existing CI scripts and file PR's against those that need fixing - a mailing list announcement that stuff *might* be broken isn't enough IMO. Just my 2c.... best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 2018-12-19 1:28 p.m., John Maddock via Boost wrote:
At the very least someone should quickly survey all the existing CI scripts and file PR's against those that need fixing - a mailing list announcement that stuff *might* be broken isn't enough IMO.
...and this is one of my biggest annoyances with Boost.Build: the fact that this isn't a stable (third-party) tool that I can simply rely on, but rather a (still !) moving target that I need to adjust to regularly in my projects. Indeed, I would have expected a change such as the one from Peter to work with projects whether they added such a yml file or not. (Of course, the advantage of the chosen strategy is to force everyone update, keeping things in sync.) Frankly, pushing such a change onto >150 projects is unacceptable in my (not so) humble opinion. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Wed, Dec 19, 2018 at 12:37 PM stefan via Boost
On 2018-12-19 1:28 p.m., John Maddock via Boost wrote:
At the very least someone should quickly survey all the existing CI scripts and file PR's against those that need fixing - a mailing list announcement that stuff *might* be broken isn't enough IMO.
...and this is one of my biggest annoyances with Boost.Build: the fact that this isn't a stable (third-party) tool that I can simply rely on, but rather a (still !) moving target that I need to adjust to regularly in my projects.
This had NOTHING to do with Boost Build. It was a Boost change. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
Rene Rivera wrote:
This had NOTHING to do with Boost Build. It was a Boost change.
Correct. It is a matter of physical organization, moving work from the superproject to submodules. Having and developing functionality in the superproject is incredibly inconvenient; doing development in a submodule is much more manageable. Unfortunately, the flip side is that the superproject is no longer self-sufficient, you have to checkout a few necessary submodules along with it. This was already true; you needed at minimum tools/build. And, since at some point tools/build was made dependent on libs/config, you then had to checkout libs/config too, for things to function. The change added two other necessary submodules to that list. This only affects people who do partial Boost checkouts in their Travis and Appveyor .yml files. If you test against a release, or a full recursive clone, nothing changes.
On 12/19/18 10:13 PM, Peter Dimov via Boost wrote:
And, since at some point tools/build was made dependent on libs/config, you then had to checkout libs/config too, for things to function.
Correction, it's Jamroot that depends on libs/config, not tools/build.
Interesting, I didn't know about that and removed the manual checkout of libs/config in a few libraries with the intention that it is pulled by depinst.py. Is this not a valid change? It would be nice if we didn't have to checkout *any* submodules except boostdep (and the library to test, of course) and then depinst would checkout everything required to run the tests.
On Thu, Dec 20, 2018 at 5:05 AM Andrey Semashev via Boost
It would be nice if we didn't have to checkout *any* submodules except boostdep (and the library to test, of course) and then depinst would checkout everything required to run the tests.
I can confirm what you said works; I do not update libs/config in my build scripts and let depinst take care of it. I also get tools/build, tools/boost_install, and libs/headers however, I don't think depinst will grab them. It would be nice if depinst pulled out tools/build, tools/boost_install, and libs/headers if you gave it a "--ci" flag. :) - Jim
Andrey Semashev wrote:
Correction, it's Jamroot that depends on libs/config, not tools/build.
Interesting, I didn't know about that and removed the manual checkout of libs/config in a few libraries with the intention that it is pulled by depinst.py. Is this not a valid change?
Technically not, but it works 99% of the time because nearly all libraries have a C++ dependency on Config, which depinst sees.
Andrey Semashev wrote:
It would be nice if we didn't have to checkout *any* submodules except boostdep (and the library to test, of course) and then depinst would checkout everything required to run the tests.
I've made this change. depinst.py now automatically installs the "essentials" libs/config, libs/headers, tools/boost_install, and tools/build.
On 12/22/18 6:43 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
It would be nice if we didn't have to checkout *any* submodules except boostdep (and the library to test, of course) and then depinst would checkout everything required to run the tests.
I've made this change. depinst.py now automatically installs the "essentials" libs/config, libs/headers, tools/boost_install, and tools/build.
Thanks!
participants (7)
-
Andrey Semashev -
Cromwell Enage -
James E. King III -
John Maddock -
Peter Dimov -
Rene Rivera -
stefan