Since sometime yesterday, all the gcc/clang develop runners I maintain (not sure about Visual Studio, that machine has been down for updates) have been failing, before the tests suite can even start running. Master still looks good. They end with the following: - bzip2 : yes [30] - lzma : yes [30] - zstd : no [30] - lzma : yes (cached) [30] - has_lzma_cputhreads builds : no [2] - auto_ptr : yes [3] error: Unable to find file or target named error: '/python//numpy' error: referred to from project at error: '../libs/python/build' I believe this is because of the python ( https://github.com/boostorg/python/pull/362) and build ( https://github.com/boostorg/build/pull/726) pull requests that were merged in around that time. The question is, why is this causing an issue....I have some vague memory of the regression test suite always using build from master? Am I remembering this correctly? If so, I think we may need to back out the python change until build's develop branch merges to master? I'm seeing this across multiple docker images, one that has been rather stable is this: https://hub.docker.com/layers/teeks99/boost-cpp-docker/clang-11/images/sha25... running with this user-config.jam: https://github.com/teeks99/boost-cpp-docker/blob/master/clang-11/user-config... and numpy installed for both python 2 and 3. Thoughts? Tom
Tom Kent wrote:
Since sometime yesterday, all the gcc/clang develop runners I maintain (not sure about Visual Studio, that machine has been down for updates) have been failing, before the tests suite can even start running. Master still looks good.
They end with the following: - bzip2 : yes [30] - lzma : yes [30] - zstd : no [30] - lzma : yes (cached) [30] - has_lzma_cputhreads builds : no [2] - auto_ptr : yes [3] error: Unable to find file or target named error: '/python//numpy' error: referred to from project at error: '../libs/python/build'
I believe this is because of the python ( https://github.com/boostorg/python/pull/362) and build ( https://github.com/boostorg/build/pull/726) pull requests that were merged in around that time. The question is, why is this causing an issue...
This is because the Build change has only been merged to https://github.com/bfgroup/b2, where the development has moved, and is not yet in boostorg/build's develop branch.
On 26/05/2021 2:17 pm, Peter Dimov wrote:
Tom Kent wrote:
Since sometime yesterday, all the gcc/clang develop runners I maintain (not sure about Visual Studio, that machine has been down for updates) have been failing, before the tests suite can even start running. Master still looks good.
They end with the following: - bzip2 : yes [30] - lzma : yes [30] - zstd : no [30] - lzma : yes (cached) [30] - has_lzma_cputhreads builds : no [2] - auto_ptr : yes [3] error: Unable to find file or target named error: '/python//numpy' error: referred to from project at error: '../libs/python/build'
I believe this is because of the python ( https://github.com/boostorg/python/pull/362) and build ( https://github.com/boostorg/build/pull/726) pull requests that were merged in around that time. The question is, why is this causing an issue...
This is because the Build change has only been merged to https://github.com/bfgroup/b2, where the development has moved, and is not yet in boostorg/build's develop branch.
Doesn't that mean that the python PR should not have been merged yet, since it depends on something not yet in Boost? (And probably the build PR shouldn't have been closed until it was merged to Boost either.)
Gavin Lambert wrote:
On 26/05/2021 2:17 pm, Peter Dimov wrote:
Tom Kent wrote: ...
I believe this is because of the python ( https://github.com/boostorg/python/pull/362) and build ( https://github.com/boostorg/build/pull/726) pull requests that were merged in around that time. The question is, why is this causing an issue...
This is because the Build change has only been merged to https://github.com/bfgroup/b2, where the development has moved, and is not yet in boostorg/build's develop branch.
Doesn't that mean that the python PR should not have been merged yet, since it depends on something not yet in Boost?
It does. I said so in the PR, but I probably should have made it a draft. In such cases usually the two PRs are merged close to each other so it doesn't become a problem, but in this case the current Build workflow prevents that.
participants (3)
-
Gavin Lambert -
Peter Dimov -
Tom Kent