Problem with re-definition of `_DEBUG` in `wrap_python.hpp`
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- build-system
Research direction
Start with include/boost/python/detail/wrap_python.hpp around line 45 and its end, then compare the _DEBUG handling with include/tbb/tbb_config.h and Blender's referenced patch. Determine how the original _DEBUG value can be preserved without breaking Boost.Python's behavior. Done means debug Blender 3.5 can build with an official Boost library without the macro-value discrepancy.
Written by the indexing model from the issue text.
Description
python/include/boost/python/detail/wrap_python.hpp undefines _DEBUG, and then redefines it as an empty macro at the end of the file.
However, this macro is not necessarily empty originally.
This discrepancy of values breaks building debug Blender 3.5 (aka current master) with any official boost library, as TBB (2020 U3) has some complex logic to handle various cases of values for _DEBUG (see include/tbb/tbb_config.h).
One could argue that the TBB 2020 code is also weak (it seems that they changed it in the more recent oneTBB), but it does rely on the value of _DEBUG to stay the same, which imho is a reasonable expectation?.
Not sure how keeping the same value for this debug could be ensured though... Maybe through BOOST_PP_ASSIGN_SLOT?
PS: For now, Blender is patching its own boost to redefine _DEBUG as 1, but this is obviously not a proper solution in general.
- Dominant language
- C++
- Stars
- 537
- Forks
- 223
- Avg merge
- 11h 22m
- Merged PRs (30d)
- 2
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from boostorg/python
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
BoostDetectToolset-1.90.0.cmake file not found in an include() call in boost_python-config.cmake Open
Difficulty 3/5 1-2 days Newbie friendliness 48/100
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100