-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libboost_stacktrace_from_exception doesn't build on macos-14 #165
Comments
One easy way to fix that would be to add
to the That's not quite right because we'd ideally want to be able to override this via If we really care about that, we can change this to
and then add I'd like to have this fixed because it breaks the boostorg/boost CI at the moment, so comments are appreciated. |
Or perhaps, given that according to #163 the feature never works on non-x86 by default, the right incantation would be
? Not sure. @grisumbras any comments? |
Optional features aren't added to the property set by default, so if there is And wouldn't your suggestion add both
|
I thought b2 was smart enough to figure out that the more specific one of these takes precedence. |
Yes, I just tried
and it works as I expected. This is not quite correct though because it doesn't handle
I think. |
To be honest, this looks too cryptic, so I'd still choose the rule. |
Eh, with the additon, no dice
|
The rule is way more cryptic to me, but I don't care one way or the other, as long as it works. |
Have I mentioned that each time I encounter an optional property, it doesn't quite work? |
Your rule, after I fix the seven or so syntax errors, doesn't seem to work. |
Fixed version:
|
I don't think this works either; we want And separately, when I tried a fixed version of your previous suggestion, |
The reason my original rule didn't work is exactly because it returned
The fixed rule in step 1 doesn't return Since all targets in Boost tree have Well, I do: make a config check:
Do we want to go there? |
Why didn't you post a working version of the previous rule? Is it
? |
No, that doesn't work either :-) |
#165 (comment) worked for me. Note, that I edited it after posting (it had a typo). |
I don't see how
can possibly work, since it checks the wrong condition ( We want to build when the architecture is x86, not when it isn't. It "worked" because This one seems to work for me, although I'm not sure how to test it for non-x86:
|
Sorry for the garbage I posted before. This one I tested with
It's basically what you posted, but I removed checking for |
PR created: #166. |
With:
(https://github.com/boostorg/boost/actions/runs/9216984858/job/25358236933)
It's exceedingly unlikely that the library will be used with libstdc++ under macOS when built with Clang, so the default on this platform should be to not build the library.
The text was updated successfully, but these errors were encountered: