Я хочу, чтобы две версии BOOST были скомпилированы в проект одновременно. В идеале они должны использоваться в следующих случаях:
boost_1_36_0::boost::shared_ptr<SomeClass> someClass = new SomeClass();
boost_1_35_0::boost::regex expression("[0-9]", boost_1_35_0::boost::regex_constants::basic);
Это было сделано для перехода на более новую версию библиотеки при устранении некоторых несовместимостей. Ничего постоянного.
@Eclipse: если вы не раскрываете какие-либо типы Boost в своих интерфейсах, вы можете использовать атрибуты видимости ELF, скрывая все, что не является общедоступным интерфейсом.





У вас возникнут проблемы со связыванием, потому что искаженные имена будут другими. И да, я вижу, вы это знали, но похоже, что вокруг будут проблемы.
Вот в чем дело. Я бы также обернул все исходные файлы регулярных выражений в каталог boostv1 с директивами пространства имен.
@ Джош:
Хотя я согласен с дрожью, я все же считаю, что это лучший курс действий. В противном случае связывание неприятностей - уверенность. Раньше у меня была ситуация, когда мне приходилось взламывать скомпилированные библиотеки с помощью objcopy, чтобы избежать конфликтов определений. Это был кошмар по причинам совместимости платформ, потому что изменение имен работает по-разному даже в разных версиях одних и тех же компиляторов (в моем случае - GCC).
Я читал (хорошо сканировал) через обсуждение списка развития. Нет простого решения. Подводить итоги:
Обертывание файлов заголовков в объявлении пространства имен
namespace boost_1_36_0 {
#include <boost_1_36_0/boost/regex.hpp>
}
namespace boost_1_35_0 {
#include <boost_1_35_0/boost/shared_ptr.hpp>
}
Определение повышения до включения заголовков
#define boost boost_1_36_0
#include <boost_1_36_0/boost/regex.hpp>
#undef boost
#define boost boost_1_35_0
#include <boost_1_35_0/boost/shared_ptr.hpp>
#undef boost
-Dboost=boost_1_36_0.Некоторые включения файла внутреннего заголовка могут быть испорчены, поскольку подобные вещи действительно случаются.
#if defined(SOME_CONDITION)
# define HEADER <boost/some/header.hpp>
#else
# define HEADER <boost/some/other/header.hpp>
#endif
Но эти случаи может быть достаточно легко обойти.
namespace boost {..} на namespace boost_1_36_0 {...} с последующим предоставлением псевдонима пространства имен. Замените все макросы BOOST_XYZ и их использование макросами BOOST_1_36_0_XYZ.
Если вы собираетесь изменить заголовки, вы можете избежать конфликтов макросов с помощью чего-то вроде 's / BOOST_ / BOOST_1_36_0_ / g'. Может быть.
Использование bcp позволяет установить библиотеку Boost в определенное место и заменить все «ускорение пространства имен» в их коде на настраиваемый псевдоним. Предполагая, что наш псевдоним «boost_1_36_0», все блоки кода «namespace boost» будут начинаться с «boost_1_36_0». Что-то типа
bcp --namespace=boost_1_36_0 --namespace-alias shared_ptr regex /path/to/install
, но проверьте документацию по ссылке самостоятельно, потому что я не уверен, является ли это допустимым синтаксисом.
Мне любопытно, зачем вам это нужно.