Использование Maven для проектов C / C ++ - PullRequest
81 голосов
/ 09 октября 2009

Я ставлю сборку Maven вокруг кластера любительского, плохо написанного и откровенно - примитивного кода C / C ++ (имеется в виду немного C, немного C ++). Проблема в том, что в настоящее время в обращении их много, и их нелегко заменить. Создание этого требует большого количества племенных знаний (вы должны перейти от куба к кубу, просто чтобы узнать, как собрать / построить различные части), а выпуск - это полный кошмар. (Нет - я не собираюсь его переписывать, пожалуйста, не спрашивайте) Мой вопрос - я должен использовать maven-native-plugin для замены множества коротких make-файлов или использовать exec-maven-plugin для простого их выполнения? У меня был довольно хороший опыт , когда последний делал .NET и не знаю, стоит ли мне инвестировать в native плагин или остаться с exec? Если бы у вас был опыт работы с Mavenizing C / C ++, я бы хотел получить совет.

1 Ответ

89 голосов
/ 09 октября 2009

Я настоятельно рекомендую maven-nar-plugin . Я считаю, что во многих отношениях он превосходит альтернативы. Он не требует перечисления исходных файлов, обрабатывает несколько операционных систем и архитектур, обрабатывает модульные и интеграционные тесты и, как правило, следует «маневренному пути». Он вводит новый тип упаковки - NAR или «собственный архив», который содержит артефакт, который вам небезразличен (.dll, .so, .a, .exe и т. Д.), А также метаданные, заголовки и т. Д. В путь, который имеет смысл.

Для упаковки стороннего программного обеспечения в NAR требуется немного предварительной работы, но это довольно просто. Когда они являются NAR, вы просто используете обычный механизм зависимостей Maven для связи с ними, например:

<dependency>
  <groupId>cppunit</groupId>
  <artifactId>cppunit</artifactId>
  <scope>test</scope>
</dependency>

Один недостаток заключается в том, что он не поддерживается активным образом, но является полнофункциональным и является довольно впечатляющим примером разработки плагинов Maven.

...