Совершенная Makefile

Question

Я хотел бы использовать make, чтобы получить модульную сборку в сочетании с continuous integration, автоматического модульного тестирования и мультиплатформенный строит. Подобные настройки распространены в Java и .NET, но мне сложно скомпоновать это для make и C/C++. Как это можно достичь?

Мои требования:

• быстро строить; нерекурсивны делают (переполнение стека вопроса What is your experience with non-recursive make?)
• модульной система (то есть минимальная зависимость, Makefile в подкаталоге с компонентами)
• мультиплатформенных (обычно PC для модульного тестирования, заливали цель для системы интеграции/выпуска)
• полной зависимость проверка
• способности выполнять (автоматический) модульные тесты (Agile инженерии)
• крючка в систему непрерывной интеграции
• легко использовать

Я начал работу с non-rec make. Я все еще считаю это прекрасным местом для начала.

Ограничения до сих пор:

• никакой интеграции блок не испытывает
• несовместимости окон компиляторов ARM на основе с путями Cygwin
• несовместимости Makefile с Windows \ путями
• зависимостей вперед

Моя структура выглядит так:

project_root 
     /algorithm 
       /src 
        /algo1.c 
        /algo2.c 
       /unit_test 
        /algo1_test.c 
        /algo2_test.c 
       /out 
        algo1_test.exe 
        algo1_test.xml 
        algo2_test.exe 
        algo2_test.xml 
      headers.h 
     /embunit 
     /harnass 
    makefile 
    Rules.top 

Я хотел бы, чтобы держать вещи простыми; здесь единичные тесты (algo1_test.exe) зависят как от компонента «алгоритм» (ok), так и от единичного тестового фреймворка (который может или не может быть известен во время его создания). Тем не менее, перемещение правил сборки в топ-код не привлекает меня, поскольку это будет распространять локальные знания компонентов во всей системе.

Что касается путей Cygwin: я работаю над созданием сборки с использованием относительных путей. Это решает проблему /cygdrive/c (поскольку компиляторы обычно могут обрабатывать/пути), не внося C: (что делает неприязнь). Любые другие идеи?

Answer 1

CMake вместе со смежными инструментами CTest и CDash, похоже, отвечают вашим требованиям. Стоит взглянуть.

Билл Хоффман (свинцовый CMake разработчик) относится к Recursive Make Considered Harmful бумаги в post в списке рассылки CMake:

...поскольку cmake создает для вас make-файлы, многие из недостатков из рекурсивного make исключены, например, вам не нужно отлаживать make-файлы или даже думать о том, как они работают. В этой статье есть другие примеры , которые исправляют cmake для вас.

См. Также this answer для "Рекурсивный макет или противник?" здесь на stackoverflow.

- Recursive Make - friend or foe?

Answer 2

Ok вот что я делаю:

Я использую один Makefile в корне и подстановочные шаблоны для сбора все файлы в каталоге. Обратите внимание, что я предполагаю, что foo/*. C будет составлять foo.so, например. Это делает сохранение Makefile минимальным, поскольку просто добавление файла в каталог автоматически добавляет его в сборку.

Поскольку вы используете, я использую (я делаю это для своих проектов), что используется компилятор, который использует синтаксис командной строки gcc (cc). Таким образом, MSC не работает; но не расстраивайтесь, я делаю большую часть своего развития (к сожалению) в Windows и использую MinGW с MSys; работает как шарм. Производит собственные двоичные файлы, но был создан с совместимой с Posix средой сборки.

Проверка зависимостей выполняется с помощью стандартного -MD. Затем я включаю все * .d файлы в Makefile. Я создаю шаблоны из автоматически собранных исходных файлов.

Окончательные модульные испытания реализованы с помощью «стандартной» цели check. Цель проверки похожа на цель, за исключением того, что она зависит от модульного теста и выполняет это, как только все будет построено. Я делаю это так, чтобы вы могли просто построить проект или построить модульные тесты (и остальную часть проекта) отдельно. Когда я не разрабатываю проект, я хочу просто создать его и сделать с ним.

Вот пример того, как я это делаю: https://github.com/rioki/c9y/blob/master/Makefile Он также имеет цели install, uninstall и dist.

Как вы можете видеть, все понятно, нет рекурсивных вызовов, и все относительно просто. Я использовал automake и autoconf, и я больше никогда этого не сделаю; другие инструменты сборки не могут быть и речи, если мне нужно установить foojam или barmake для создания чего-то, я обычно отказываюсь от этого проекта немедленно.