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.
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
_DEBUGto 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
_DEBUGas 1, but this is obviously not a proper solution in general.