Как мне интегрировать и упаковывать эту стороннюю библиотеку в приложение Win32 C ++?

Question

У нас есть (очень большая) существующая кодовая база для настраиваемого элемента управления ActiveX, и я хотел бы интегрировать libkml в него для взаимодействия с данными отображения KML, а не изобретать рулевое колесо. Проблема в том, что я являюсь относительно новым разработчиком для Windows и, исходя из мира Linux, я действительно не уверен, каков правильный способ интеграции сторонней библиотеки. К счастью, libkml предоставляет проекты MSVCC для его компиляции, поэтому перенос не является проблемой. Я думаю, у меня есть пара вариантов, о которых я могу подумать:

1. Построить и связать библиотеку напрямую . У нас уже есть решение с файлами проекта в нем для «основного» проекта; Я мог бы добавить libkml проекты к этому решению, но я бы не хотел. Маловероятно, что код libkml изменится по отношению к коду нашего приложения.

2. Статическая ссылка на файлы .lib, созданные в libkml build . Это непривлекательно, так как из решения libkml вышло шесть .lib файлов, и, кажется, нелегко вручную указать их в параметрах компоновщика и т. Д.

3. Упакуйте код как есть в DLL . Может быть с COM? Кажется, что если бы я сделал это без какого-либо перевода, я бы в итоге получил много накладных расходов, и, поскольку я довольно незнаком с COM, я не знаю, сколько работы потребуется для раскрытия всей функциональности, которую я испытываю ». Я хотел бы использовать через COM. Библиотека довольно большая, имеет много классов, которые она использует, и если бы мне пришлось вручную писать код, чтобы разоблачить все это, я бы не решился пойти по этому пути.

4. Напишите код-обертку, чтобы абстрагировать нужную мне функциональность, упакуйте ее в COM DLL и взаимодействуйте с ней . Это кажется разумным, я полагаю, но трудно определить, сколько абстракции мне нужно, так как я еще не написал код, который бы использовал libkml.

Позвольте мне повторить: я еще не написал код, который будет взаимодействовать с libkml, так что он в основном экспериментальный. Опции 1 и 2 также усложняются тем фактом, что libkml опирается дополнительно на еще три внешних библиотеки, которые также находятся в файлах .lib (которые мне пришлось все равно перекомпилировать, чтобы выстроить флаги генерации кода). Очевидно, что цель состоит в том, чтобы заставить код работать, но ремонтопригодность и организация дерева исходных текстов также являются целями, поэтому я склоняюсь к вариантам 3 и 4, но я не знаю, как лучше всего подойти к ним в Windows.

Answer 1

Может быть, я что-то здесь упускаю, но я действительно не вижу, что не так с (1). Я думаю, что даже если у вас было несколько проектов, которые использовали libkml, просто вставьте файл проекта для libkml в файл решения, укажите зависимости, и все готово. Это очень просто. Даже решение (2) очень просто. Если библиотеки когда-нибудь изменятся, вы перестраиваете - вам все равно придется это делать.

Я не вижу, как (3) или (4) необходимы или даже желательны. Для меня это звучит как большая работа для целей (организация дерева исходных текстов и ремонтопригодность), что я даже не уверен, что эти варианты действительно соответствуют. Фактически, вы сами сказали, что «маловероятно, что код libkml изменится по отношению к коду нашего приложения».

То, что я нашел за эти годы, - это просто все упростить. Если перестройка KML может занять много времени, возьмите библиотеки и просто статически связывайте их с библиотеками. Да, есть и другие зависимости, но вы настроите их один раз, и все будет готово, надеюсь, вы больше никогда не будете беспокоиться об этом. В противном случае, вставьте его в проект и двигайтесь дальше. Я думаю, что стоит спросить, стоит ли тратить много времени на эту проблему.

Answer 2

Ввод шести имен файлов или использование декларативного стиля с комментарием #pragma (lib, "foo.lib") - это маленький картофель по сравнению с работой, которую вам придется сделать, чтобы превратить это в DLL или COM-сервер.

Дистрибутив сильно склоняется к использованию его в качестве статической библиотеки ссылок.Есть только пятнистые объявления, которые можно превратить в DLL с помощью __declspec (dllexport).Они существуют только в сторонних зависимостях.Конечно, используя все #defines, вы наберете несколько имен в определениях препроцессора для проектов.

Кроме того, вам будет сложно загрузить эту DLL во время выполнения, поскольку вы используете ее на COM-сервере.Путь поиска для DLL будет клиентским приложением, когда COM создаст ваш управляющий экземпляр, и вряд ли будет близко к месту, где вы развернули DLL.

Создание COM-сервера - это много работы, вам придется написать весь интерфейсный клей самостоятельно.Опять же, в исходном коде уже нет ничего, что могло бы помочь с этим вообще.

Answer 3

Вы также можете обернуть все необходимые функции в не-COM-DLL. Visual studio поддерживает создание статической библиотеки-оболочки, которая при связывании заставит вашу программу использовать dll. Таким образом, вы можете указать только одну зависимость вместо шести.

Кроме того, что не так с указанием шести зависимостей. Я бы предположил, что есть веская причина, по которой это шесть отдельных библиотек вместо одной, поэтому разумно указать, какие именно части вы на самом деле используете.