Сценарий состоит в том, что мы хотим использовать сторонний компонент (исходный код) для нашего проекта, который использует определенное c пространство имен.
Мы предоставляем наше программное обеспечение в качестве библиотеки для клиентов.
Теперь заказчик хочет использовать в приложении один и тот же компонент (может быть, ту же версию, может быть, другой) и добавляет компонент (исходные файлы + заголовок) в свой проект. Таким образом, пространство имен компонента используется дважды ...
- компонент компилируется в нашу библиотеку
- клиент также пытается построить компонент
Здесь у нас могут возникнуть проблемы с ошибками компоновщика.
Теперь, если клиент хочет использовать ту же версию компонента, мы можем экспортировать API компонента с нашим собственным API - это должно работать (клиент должен просто используйте компонент через наш API).
Но что, если клиент захочет использовать другую версию компонента?
Возможно, мы могли бы попытаться обернуть другое пространство имен вокруг пространства имен компонента, но это может стать уродливым.
Какое хорошее решение для этой проблемы?
Обновление
Настройка нашей библиотеки:
./src/foo.cpp
./include/foo.h
./thirdparty/comp_v1.0/src/comp.cpp
./thirdparty/comp_v1.0/include/comp.h
- с сторонним программным обеспечением
comp с использованием пространства имен comp_n - и
foo.cpp, включая comp.h
Теперь мы создаем библиотеку - в этом случае не связывает stati c или dyn ami c против библиотеки comp, но с использованием исходного кода comp.
Мы отправляем библиотеку:
foo/lib/libfoo.a
foo/include/libfoo.h
foo/include/comp.h # optional
У клиента есть проект для приложения, и он включает нашу библиотеку foo, а также исходный код comp:
src/main.cpp
thirdparty/foo/lib/libfoo.a
thirdparty/foo/include/foo.h
thirdparty/foo/include/comp.h # optional
thirdparty/comp_v1.5/src/foo.cpp
thirdparty/comp_v1.5/include/foo.h
Поэтому он использует тот же компонент, который встроен в нашу библиотеку, но возможно, другая версия.
- Если клиент согласен использовать ту же версию, мы можем отправить
comp.h с нашей библиотекой, и клиент просто не добавит comp в свой проект. - Если клиент хочет использовать другую версию, мы не должны поставлять
comp.h, но все же у клиента возникнут проблемы со сборкой comp.cpp (компоновщик будет жаловаться), поскольку компонент уже существует в нашей библиотеке.
Это будет довольно много кода + несколько скриптов сборки cmake, которые обеспечат настоящий MCVE. Если кто-то понимает проблему или столкнулся с чем-то. аналогично, я надеюсь, что исчерпывающего описания (как я надеюсь вышеизложенного) должно быть достаточно.