Comments (19)
One easy way to fix that would be to add
<architecture>arm,<target-os>darwin,<toolset>clang:<build>no
to the boost_stacktrace_from_exception
requirements.
That's not quite right because we'd ideally want to be able to override this via boost.stacktrace.from_exception=on
, but this isn't possible currently because on
is the default value of this feature, so we can't know whether it was explicitly given.
If we really care about that, we can change this to
feature.feature boost.stacktrace.from_exception : default on off : optional propagated ;
and then add <boost.stacktrace.from_exception>default
to the conditions above.
I'd like to have this fixed because it breaks the boostorg/boost CI at the moment, so comments are appreciated.
from stacktrace.
Or perhaps, given that according to #163 the feature never works on non-x86 by default, the right incantation would be
<build>no
<boost.stacktrace.from_exception>on:<build>yes
<architecture>x86:<build>yes
?
Not sure. @grisumbras any comments?
from stacktrace.
Optional features aren't added to the property set by default, so if there is <boost.stacktrace.from_exception>on
in the property set, then it was explicitly added.
And wouldn't your suggestion add both <build>no
and <build>yes
to the property set? It should probably use a conditional property with a rule
rule build_from_exception( props * )
{
local result = [ property.select <build> : $(props) ] ;
if $(result) { return $(result) ; }
local enabled = [ property.select <boost.stacktrace.from_exception> ] ;
switch $(enabled:G)
{
case on: return ;
case off: return <build>no;
}
if [ property.select <architecture> ] != x86
{
return <build>no ;
}
}
from stacktrace.
And wouldn't your suggestion add both
<build>no
and<build>yes
to the property set?
I thought b2 was smart enough to figure out that the more specific one of these takes precedence.
from stacktrace.
Yes, I just tried
<build>no
<architecture>x86:<build>yes
<boost.stacktrace.from_exception>on:<build>yes
and it works as I expected.
This is not quite correct though because it doesn't handle <boost.stacktrace.from_exception>off
correctly, it should be
<build>no
<architecture>x86:<build>yes
<boost.stacktrace.from_exception>on:<build>yes
<architecture>x86,<boost.stacktrace.from_exception>off:<build>no
I think.
from stacktrace.
To be honest, this looks too cryptic, so I'd still choose the rule.
from stacktrace.
Eh, with the additon, no dice
C:/boost-git/develop/tools/build/src/build\targets.jam:1133: in evaluate-requirements from module targets
error: Can not evaluate conditional properties <architecture>x86,<boost.stacktrace.from_exception>off:<build>no <architecture>x86:<build>yes <boost.stacktrace.from_exception>on:<build>yes <conditional>@Jamfile<C:\boost-git\develop>%Jamfile<C:\boost-git\develop>.clang-darwin-cxxstd-11 <conditional>@Jamfile<C:\boost-git\develop>%Jamfile<C:\boost-git\develop>.handle-static-runtime <conditional>@Jamfile<C:\boost-git\develop>%boostcpp.deduce-address-model <conditional>@Jamfile<C:\boost-git\develop>%boostcpp.deduce-architecture <conditional>@Jamfile<C:\boost-git\develop>%threadapi-feature.detect <conditional>@object(check-target-builds-worker)@10081%check <python>2.7,<target-os>windows:<python.interpreter>C:/Python27\python <python>3.9,<target-os>windows:<python.interpreter>C:/Python39\python <target-os>linux:<library>/C:/boost-git/develop/libs/stacktrace/build//dl <toolset>como-linux:<define>_GNU_SOURCE=1 <toolset>como:<link>static <toolset>msvc,<runtime-link>shared:<threading>multi
from stacktrace.
The rule is way more cryptic to me, but I don't care one way or the other, as long as it works.
from stacktrace.
Have I mentioned that each time I encounter an optional property, it doesn't quite work?
from stacktrace.
Your rule, after I fix the seven or so syntax errors, doesn't seem to work.
from stacktrace.
Fixed version:
import property ;
rule build-from-exception ( props * )
{
local result = [ property.select <build> : $(props) ] ;
if $(result) { return $(result) ; }
local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
switch $(enabled:G=)
{
case "on" : return ;
case off : return <build>no ;
}
local arch = [ property.select <architecture> : $(props) ] ;
if $(arch) && ( $(arch) = x86 )
{
return <build>no ;
}
}
from stacktrace.
I don't think this works either; we want <build>no
when the architecture isn't x86, not when it is.
And separately, when I tried a fixed version of your previous suggestion, b2 build boost.stacktrace.from_exception=on
didn't build the library for some reason.
from stacktrace.
The reason my original rule didn't work is exactly because it returned <build>no
when <architecture>
was not in the property set. It went like this:
- My rule is evaluated, it returns
<build>no
because no<architecture>
. boostcpp.deduce-architecture
is evaluated, it returns<architecture>x86
.- My rule is evaluated again with the updated property set. The property set has
<build>no
from step 1, so that's what it is returning.
The fixed rule in step 1 doesn't return <build>no
if no <architecture>
, so on step 3 it can see that the architecure is in fact x86.
Since all targets in Boost tree have <conditional>@boostcpp.deduce-architecture
, this will work for all deducible architectures. For non-deducible architectures I don't have a solution, I'm afraid.
Well, I do: make a config check:
import property ;
import configure ;
import boostcpp ;
rule build-from-exception ( props * )
{
local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
switch $(enabled:G=)
{
case "on" : return ;
case off : return <build>no ;
}
local arch = [ property.select <architecture> : $(props) ] ;
if $(arch) && ( $(arch) = x86 )
{
return ;
}
local filtered = [ boostcpp.toolset-properties $(props) ] ;
local deduced = [ configure.find-builds "default architecture" : $(filtered)
: /boost/architecture//x86 ] ;
if $(deduced)
{
return ;
}
return <build>no ;
}
Do we want to go there?
from stacktrace.
Why didn't you post a working version of the previous rule? Is it
rule build-from-exception ( props * )
{
local result = [ property.select <build> : $(props) ] ;
if $(result) { return $(result) ; }
local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
switch $(enabled:G=)
{
case "on" : return ;
case off : return <build>no ;
}
local arch = [ property.select <architecture> : $(props) ] ;
if $(arch) && ( $(arch) = x86 )
{
return ;
}
return <build>no ;
}
?
from stacktrace.
No, that doesn't work either :-)
from stacktrace.
Why didn't you post a working version of the previous rule?
#165 (comment) worked for me. Note, that I edited it after posting (it had a typo).
from stacktrace.
I don't see how
local arch = [ property.select <architecture> : $(props) ] ;
if $(arch) && ( $(arch) = x86 )
{
return <build>no ;
}
can possibly work, since it checks the wrong condition (=
instead of !=
).
We want to build when the architecture is x86, not when it isn't.
It "worked" because = x86
is never true because of the missing :G=
.
This one seems to work for me, although I'm not sure how to test it for non-x86:
rule build-stacktrace-from-exception ( props * )
{
local build = [ property.select <build> : $(props) ] ;
local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
local arch = [ property.select <architecture> : $(props) ] ;
if $(build)
{
return $(build) ;
}
switch $(enabled:G=)
{
case "on" : return ;
case "off" : return <build>no ;
}
if $(arch) && ( $(arch:G=) != x86 )
{
return <build>no ;
}
}
from stacktrace.
Sorry for the garbage I posted before. This one I tested with
b2 libs/stacktrace/build
(builds), b2 libs/stacktrace/build boost.stacktrace.from_exception=on
(builds), b2 libs/stacktrace/build boost.stacktrace.from_exception=off
(doesn't build), b2 libs/stacktrace/build architecture=arm
(doesn't build), b2 libs/stacktrace/build architecture=arm boost.stacktrace.from_exception=off
(doesn't build), and b2 libs/stacktrace/build architecture=arm boost.stacktrace.from_exception=on
(tries to build, but fails as expected).
import property ;
rule build-from-exception ( props * )
{
local enabled = [ property.select <boost.stacktrace.from_exception> : $(props) ] ;
switch $(enabled:G=)
{
case "on" : return ;
case off : return <build>no ;
}
local arch = [ property.select <architecture> : $(props) ] ;
if $(arch) && ( $(arch:G=) != x86 )
{
return <build>no ;
}
}
It's basically what you posted, but I removed checking for <build>
, as it is unnecessary.
from stacktrace.
PR created: #166.
from stacktrace.
Related Issues (20)
- msvc-based stacktrace should also allow to determine the module image path
- safe_dump_to causes a deadlock if signal is received when throwing an exception HOT 3
- Symbol redefinition on latest mingw gcc HOT 6
- Error when compiling boost since MSYS2 update (02/2023) HOT 1
- BOOST_STACKTRACE_USE_WINDBG is missing in windbg.cpp HOT 1
- AV in debugging_symbols::get_source_file_line_impl during app finalization HOT 3
- gcc warnings with -Wshadow compiler flag HOT 1
- Symbolizer markup format
- Missing #include's during `./b2` invocation HOT 1
- from_dump unable to load safe_dump_to file HOT 1
- B2: `<visibility>hidden` as a requirement HOT 2
- [win32] crash with 0xC000000D in dll after exit() was called HOT 3
- How to build boost_stacktrace_from_exception HOT 4
- "WinSock.h has already been included" HOT 1
- Documentation example call `std::stacktrace::from_current_exception()` rather than `boost::` HOT 1
- ./boost/stacktrace/detail/libbacktrace_impls.hpp:135:32: error: no matches converting function ‘libbacktrace_syminfo_callback’ to type ‘backtrace_syminfo_callback’ {aka ‘void (*)(void*, long unsigned int, const char*, long unsigned int, long unsigned int, const char*, long unsigned int)’} HOT 1
- What set of b2 options builds the boost_stacktrace_from_exception library? HOT 6
- stacktrace_from_exception on non-x86 HOT 2
- stacktrace_from_exception contains misleading assert-message HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stacktrace.