On Thu, Feb 19, 2015 at 11:59 AM, Vladimir Prus
Hi,
it seems that Boost.Log defines, and checks, it's own log-address-model and log-architecture and log-instruction-set properties. Naturally, if I'm trying to make regular address-model and architecture properties always set, these are getting in the way.
Do we really need per-library properties? If a user wants to build Boost.Log with a particular architecture, I would think he can do:
./b2 --with-log <whatever>
If so, is everybody fine if I eliminate these custom features eventually?
The custom features are needed to enable specific compiler options and source files when building the library. They need not be Boost.Log-specific, but I could not find any other way to achieve what I wanted. Please, do not remove these features with haste. Could you explain what is the problem with these features and what is the proposed fix?