Added Boost.Predef to check environment such as endian. #312
Conversation
https://github.com/boostorg/predef.git has been added as a submodule on external/boost/predef. In order to avoid macro name conflicts, replaced "BOOST_" with "MSGPACK_" and "boost/" with "msgpack/" then copy replaced files to include/msgpack. This process is described in CMakeLists.txt. Replaced files are included as a part of msgpack-c. So you don't need to do the converting process each time. Fixed endian checking logic.
|
@redboltz Although it runs smoothly, changing |
|
@ygj6 , depending on boost is not a problem for me. But some of committers and users want to remove the dependency of boost. As far as I remember, they use older version of boost and it is not enough for msgpack-c. They don't want to update their boost by some reason. Mixing two different version of boost is very difficult to manage. So I apply converting process. I think that @nobu-k knows the reason. @nobu-k , what do you think the current situation? |
|
Maybe we can start a poll to decide what to do, or create a new branch for a version that depends on |
|
I suffered with an issue caused by weak references that happened by linking two libraries depending on two different versions of boost (it was quite a messy on-premise environment without something like container isolation). I don't remember which part of boost caused that, but it was like a constructor and a destructor were loaded from different versions of implementations. It was around 10 years ago, and we now have many ways to isolate runtime environments. So, in terms of that issue, I think it's now a lot less severe. However, I believe we have to clarify which version of boost msgpack-c supports. Also, I'm personally away from C++ for several years now, and don't know how majority of msgpack-c users feel about boost being a requirement for building (or perhaps using?) msgpack-c recently. So, it might be good to start a poll, but I'd basically follow your decision. |
Boost in msgpack-c have been updated from 1.58.0 to 1.61.0, and then from 1.61.0 to 1.68.0 . Also, I just recently tested the latest
Perhaps the system has improved dependencies in recent years. Anyway, it is worthwhile trying to cut off internal
Maybe we can start a voting issue and pin it? |
3 participants
https://github.com/boostorg/predef.git has been added as a submodule on
external/boost/predef.
In order to avoid macro name conflicts, replaced "BOOST_" with "MSGPACK_"
and "boost/" with "msgpack/" then copy replaced files to include/msgpack.
This process is described in CMakeLists.txt.
Replaced files are included as a part of msgpack-c. So you don't need to
do the converting process each time.
Fixed endian checking logic.