Builds from boost/status fail early?
Using develop from this morning (tried various combinations of these three options...): boost@d48d3305d4b4:/boost/status$ ../b2 toolset=clang variant=release cxxstd=03 ... /boost/tools/build/src/build/feature.jam:491: in validate-value-string from module feature error: "shared:" is not a known value of feature <link> error: legal values: "shared" "static" /boost/tools/build/src/build/feature.jam:365: in expand-subfeatures-aux from module feature /boost/tools/build/src/build/feature.jam:422: in expand-subfeatures from module feature /boost/tools/build/src/build/feature.jam:871: in feature.expand from module feature /boost/tools/build/src/build/targets.jam:1103: in evaluate-requirements from module targets /boost/tools/build/src/build/targets.jam:1121: in common-properties2 from module targets /boost/tools/build/src/build/targets.jam:1017: in targets.common-properties from module targets /boost/tools/build/src/build/targets.jam:1313: in class@basic-target.generate from module object(typed-target)@47912 /boost/tools/build/src/build/targets.jam:812: in generate-really from module object(main-target)@70272 /boost/tools/build/src/build/targets.jam:784: in class@main-target.generate from module object(main-target)@70272 /boost/tools/build/src/build/targets.jam:273: in class@project-target.generate from module object(project-target)@47307 /boost/tools/build/src/build/targets.jam:273: in class@project-target.generate from module object(project-target)@4568 /boost/tools/build/src/build-system.jam:797: in load from module build-system /boost/tools/build/src/kernel/modules.jam:295: in import from module modules /boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /boost/boost-build.jam:17: in module scope from module
AMDG On 10/27/2018 11:07 AM, James E. King III via Boost wrote:
Using develop from this morning (tried various combinations of these three options...):
boost@d48d3305d4b4:/boost/status$ ../b2 toolset=clang variant=release cxxstd=03 ... /boost/tools/build/src/build/feature.jam:491: in validate-value-string from module feature error: "shared:" is not a known value of feature <link> error: legal values: "shared" "static"
This looks like a conditional gone wrong, but I can't reproduce the problem. Steps to track this down: - run the b2 debugger: b2 -dconsole - set a breakpoint at errors.error: break errors.error - Start the program: run toolset=clang variant=release cxxstd=03 - Find out which target is the source of the error: backtrace print [ object(typed-target)@47912.location ] (substitute the actual object name that appears on the stack)
<snip> /boost/tools/build/src/build/targets.jam:1313: in class@basic-target.generate from module object(typed-target)@47912 /boost/tools/build/src/build/targets.jam:812: in generate-really from module object(main-target)@70272 <snip>
In Christ, Steven Watanabe
On Sat, Oct 27, 2018 at 4:53 PM Steven Watanabe via Boost < boost@lists.boost.org> wrote:
AMDG
Using develop from this morning (tried various combinations of these
On 10/27/2018 11:07 AM, James E. King III via Boost wrote: three
options...):
boost@d48d3305d4b4:/boost/status$ ../b2 toolset=clang variant=release cxxstd=03 ... /boost/tools/build/src/build/feature.jam:491: in validate-value-string from module feature error: "shared:" is not a known value of feature <link> error: legal values: "shared" "static"
This looks like a conditional gone wrong, but I can't reproduce the problem.
Steps to track this down: - run the b2 debugger: b2 -dconsole - set a breakpoint at errors.error: break errors.error - Start the program: run toolset=clang variant=release cxxstd=03 - Find out which target is the source of the error: backtrace print [ object(typed-target)@47912.location ] (substitute the actual object name that appears on the stack)
<snip> /boost/tools/build/src/build/targets.jam:1313: in class@basic-target.generate from module object(typed-target)@47912 /boost/tools/build/src/build/targets.jam:812: in generate-really from module object(main-target)@70272 <snip>
In Christ, Steven Watanabe
I find it both amazing and scary that Boost.Build has an interactive
debugger.
In any case, if you use the docker container in the pull request in
boostorg/boost
you would probably be able to reproduce this because it pulls in
dependencies
of many of the repositories. For example the docker container is using
Python 3.6.
(might I suggest aliasing "bt" for "backtrace" in the Boost.Build debugger?)
```
(b2db) backtrace
#0 in errors.error ( "shared:" is not a known value of feature <link> :
legal values: "shared" "static" ) at
/boost/tools/build/src/kernel/errors.jam:149
#1 in validate-value-string ( <link> shared: ) at
/boost/tools/build/src/build/feature.jam:491
#2 in expand-subfeatures-aux ( <link> : shared: : ) at
/boost/tools/build/src/build/feature.jam:365
#3 in expand-subfeatures ( <link>shared:
AMDG On 10/27/2018 03:11 PM, Peter Dimov via Boost wrote:
James E. King III wrote:
../libs/statechart/test/Jamfile.v2:40: Unescaped special character in argument <link>shared:
There you go.
Yep. The expected output should be: ..\libs\statechart\test\Jamfile.v2:40: Unescaped special character in argument <link>shared:$(dll-export) In Christ, Steven Watanabe
AMDG On 10/27/2018 03:05 PM, James E. King III wrote:
On Sat, Oct 27, 2018 at 4:53 PM Steven Watanabe via Boost < boost@lists.boost.org> wrote:
<snip> I find it both amazing and scary that Boost.Build has an interactive debugger. In any case, if you use the docker container in the pull request in boostorg/boost you would probably be able to reproduce this because it pulls in dependencies of many of the repositories. For example the docker container is using Python 3.6.
(might I suggest aliasing "bt" for "backtrace" in the Boost.Build debugger?)
That's reasonable, but I'd actually like to match gdb's command alias/abbreviations systematically rather than adding individual aliases on an ad-hoc basis.
``` <snip> #10 in class@main-target.generate ( object(property-set)@73156 ) at /boost/tools/build/src/build/targets.jam:784 <snip> ```
so: ``` (b2db) print [ object(typed-target)@73156.location ] (builtin):1: in errors.error ERROR: rule "object(typed-target)@73156.location" unknown in module "errors".
Well, that shows a clear deficiency in the debugger. @73156 is a property-set (hence the error) and the id of the object that you need is not shown anywhere. In Christ, Steven Watanabe
Steven Watanabe wrote:
(might I suggest aliasing "bt" for "backtrace" in the Boost.Build debugger?)
That's reasonable, but I'd actually like to match gdb's command alias/abbreviations systematically rather than adding individual aliases on an ad-hoc basis.
`bt` is a gdb abbreviation though. :-)
AMDG On 10/27/2018 04:58 PM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
(might I suggest aliasing "bt" for "backtrace" in the Boost.Build > debugger?)
That's reasonable, but I'd actually like to match gdb's command alias/abbreviations systematically rather than adding individual aliases on an ad-hoc basis.
`bt` is a gdb abbreviation though. :-)
I know. All I'm saying is that I also want to add support for: "The names where and info stack (abbreviated info s) are additional aliases for backtrace." "You can abbreviate a GDB command to the first few letters of the command name, if that abbreviation is unambiguous" r (run), s (step), b (break), etc. at the same time. In Christ, Steven Watanabe
James E. King III wrote:
Using develop from this morning (tried various combinations of these three options...):
boost@d48d3305d4b4:/boost/status$ ../b2 toolset=clang variant=release cxxstd=03 ... /boost/tools/build/src/build/feature.jam:491: in validate-value-string from module feature error: "shared:" is not a known value of feature <link> error: legal values: "shared" "static"
I suspect this as the cause: ../libs/statechart/test/Jamfile.v2:40: Unescaped special character in argument <link>shared:$(dll-export) ../libs/statechart/test/Jamfile.v2:105: Unescaped special character in argument <link>shared:$(dll) Haven't looked at it too deeply though. You can exclude statechart from the tests by using `--exclude-tests=statechart`.
On Sat, Oct 27, 2018 at 5:04 PM Peter Dimov via Boost
Using develop from this morning (tried various combinations of these
James E. King III wrote: three
options...):
boost@d48d3305d4b4:/boost/status$ ../b2 toolset=clang variant=release cxxstd=03 ... /boost/tools/build/src/build/feature.jam:491: in validate-value-string from module feature error: "shared:" is not a known value of feature <link> error: legal values: "shared" "static"
I suspect this as the cause:
../libs/statechart/test/Jamfile.v2:40: Unescaped special character in argument <link>shared:$(dll-export) ../libs/statechart/test/Jamfile.v2:105: Unescaped special character in argument <link>shared:$(dll)
Haven't looked at it too deeply though.
You can exclude statechart from the tests by using `--exclude-tests=statechart`.
That was it. Thank you! I was trying to use --without-statechart but that doesn't work. Where do we run boost builds in boost/status in CI? Should have caught this earlier. In any case, I already filed an issue for this. statechart is one of two remaining CMT repositories (along with disjoint_sets) i haven't gotten through sanitizing yet. - Jim
James E. King III wrote:
Where do we run boost builds in boost/status in CI? Should have caught this earlier.
The whole `status` is way too expensive for CI, so the superproject runs it with `b2 -n` to catch Jamfile errors (this would have caught your problem, but it doesn't show up there - for some reason $(dll-export) seems to be missing in your case, but it's there on develop. It's probably something in your local copy.) The superproject also runs a "quick" status, which consists of going through the test Jamfiles and running the `quick` target, if they have one. (`run quick.cpp ;` usually.) But not many projects have these, because I haven't advertised this. :-)
On Sat, Oct 27, 2018 at 5:20 PM Peter Dimov via Boost
The whole `status` is way too expensive for CI, so the superproject runs it with `b2 -n` to catch Jamfile errors (this would have caught your problem, but it doesn't show up there - for some reason $(dll-export) seems to be missing in your case, but it's there on develop. It's probably something in your local copy.)
That unescaped colon is on develop; not sure why the superproject build wouldn't have caught this. In any case I have a PR out to fix. In this case based on changes in Boost.Function I wanted to run everything to make sure there were no regressions. - Jim
AMDG On 10/27/2018 03:20 PM, Peter Dimov via Boost wrote:
James E. King III wrote:
Where do we run boost builds in boost/status in CI? Should have caught this earlier.
The whole `status` is way too expensive for CI, so the superproject runs it with `b2 -n` to catch Jamfile errors (this would have caught your problem, but it doesn't show up there - for some reason $(dll-export) seems to be missing in your case, but it's there on develop. It's probably something in your local copy.)
It's not even that it's missing. It has to be defined and hold an empty string to cause this. I just don't see how this is possible.
The superproject also runs a "quick" status, which consists of going through the test Jamfiles and running the `quick` target, if they have one. (`run quick.cpp ;` usually.) But not many projects have these, because I haven't advertised this. :-)
In Christ, Steven Watanabe
participants (3)
-
James E. King III -
Peter Dimov -
Steven Watanabe