организация внешних библиотек и включаемых файлов - PullRequest
Новая
       4

организация внешних библиотек и включаемых файлов

3 голосов
/ 17 июня 2010

С годами в моих проектах используется все больше внешних библиотек, и то, как я это делал, становится все более и более неловким (хотя, надо сказать, это работает безупречно). Я использую VS в Windows, CMake в других и CodeComposer для работы с процессорами цифровых сигналов (DSP) в Windows. За исключением DSP, используются как 32-битные, так и 64-битные платформы.

Вот пример того, что я делаю сейчас; обратите внимание, что, как показано, разные внешние библиотеки не всегда организованы одинаково. Некоторые из них имеют разные папки lib / include / src, другие имеют одну папку src. Некоторые были готовы к использованию со статическими и / или общими библиотеками, другие были построены 

/path/to/projects
                 /projectA
                 /projectB

/path/to/apis
             /apiA
                  /src
                  /include
                  /lib

             /apiB
                  /include
                  /i386/lib
                  /amd64/lib

/path/to/otherapis
                  /apiC
                      /src

/path/to/sharedlibs
                  /apiA_x86.lib       -->some libs were built in all possible configurations
                  /apiA_x86d.lib
                  /apiA_x64.lib
                  /apiA_x64d.lib
                  /apiA_static_x86.lib
                  /apiB.lib           -->other libs have just one import library

/path/to/dlls                         -->most of this directory also gets distributed to clients
             /apiA_x86.dll               and it's in the PATH
             /apiB.dll

Каждый раз, когда я добавляю внешнюю библиотеку, я примерно использую этот процесс:

  • при необходимости соберите его для разных конфигураций (релиз / отладка / платформа)
  • скопировать статические библиотеки и / или импортировать их в «sharedlibs»
  • скопировать общие библиотеки в 'dlls'
  • добавить переменную среды, например, 'API_A_DIR', которая указывает на корень для ApiA, например '/ path / to / apis / apiA'
  • создать лист свойств VS и файл CMake для указания пути включения и, в конечном итоге, имени библиотеки, например include = '$ (API_A_DIR) / Include' и lib = apiA.lib
  • добавить файл правильной таблицы / cmake в проект, которому нужна библиотека

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

Я думал о том, чтобы избавиться от переменных среды для каждой библиотеки и использовать только один «API_INCLUDE_DIR» и упорядоченно заполнить его включаемыми файлами: 

/path/to/api/include
                    /apiA
                    /apiB
                    /apiC

Таким образом, мне не нужен ни путь включения в соответствующих таблицах, ни переменные среды. Для библиотек, которые используются только в окнах, мне даже не нужна таблица свойств, так как я могу использовать #pragmas, чтобы указать компоновщику, на какую библиотеку ссылаться. Также в коде будет более понятно, что включается, и нет необходимости для оболочек включать файлы с одинаковыми именами, но из разных библиотек: 

#include <apiA/header.h>
#include <apiB/header.h>
#include <apiC_version1/header.h>

Снятие средств со счета происходит из-за того, что мне приходится копировать включаемые файлы и, возможно, ** вносить дубликаты в файловую систему, но это похоже на незначительную цену, не так ли?

** на самом деле, когда библиотеки собраны, единственное, что мне нужно от них, - это включаемые файлы и их библиотеки. Поскольку у каждого из них будет выделенный каталог, исходное дерево исходных текстов больше не нужно, поэтому его можно удалить.

1 Ответ

1 голос
/ 17 июня 2010

Почему бы не использовать ссылки на файловую систему?

ln -s /path/to/apis/apiA/include /path/to/api/include/apiA

Voilá.Подобное можно сделать в Windows, но у меня пока нет командной строки.

...