Re: What to do about Boost libraries which use user-defined macros which are not BOOST_ prefixed

From: pbristow_at_[hidden]
Date: 2019-12-16 17:27:05

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Niall Douglas via
Boost
> Sent: 16 December 2019 15:22
> To: Boost Developers List <boost_at_[hidden]>
> Cc: Niall Douglas <s_sourceforge_at_[hidden]>
> Subject: [boost] What to do about Boost libraries which use user-defined
macros
> which are not BOOST_ prefixed
> 
> Acting on guidance given to my recent supply to this list of unprefixed
macros,
> namespaces etc injected into the global namespace by Boost, I have logged a
list of
> all issues with each library, and linked to all those from a single issue
logged at
> https://github.com/boostorg/boost/issues/352.
> 
> A problem has arisen which requires input from boost-dev. Some Boost libraries
> define as part of their public API a non-BOOST_-prefixed macro which changes
the
> definition of their header files e.g.
> 
> PHOENIX_LIMIT
> 
> (just to be clear, Phoenix is not the only library doing this)
> 
> If we change such macros to be like BOOST_PHOENIX_LIMIT instead, all existing
> code using Boost which sets PHOENIX_LIMIT would potentially
> *silently* break.
> 
> What we could decide to do instead is:
> 
> #if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT) #error In Boost
> 1.xx PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT.
> Please upgrade your code to reflect the new name.
> #endif
> 
> Or one could just leave PHOENIX_LIMIT named as is.
> 
> What would Boost developers prefer we do?

Is it only Boost libraries that define this macro?

People have bureaucratic hurdles and hoop to jump over through as well as doing
a quick grep-replace.

It has been Boost normal practice to give people time to make changes rather
than breaking things without warning.

Would it be sensible that we combine these two by doing Peter's suggestion now,
and Niall's after at least one Boost release?

Paul