Каков ваш опыт работы с нерекурсивными программами? [закрыто]

Я знаю о по крайней мере одном крупномасштабном проекте ( КОРЕНЬ ), который рекламирует использование [powerpoint ссылка] , механизм, описанный в Рекурсивном, Делает Продуманными Вредный. Платформа превышает миллион строк кода и компиляций вполне энергично.

И, конечно, все великоватые проекты я работаю с тем , делают , используют рекурсивный, делают, мучительно не спешат компилировать.:: вздох::

Позвольте мне подчеркнуть один аргумент статьи Miller's: Когда Вы начинаете вручную разрешать отношения зависимости между различными модулями и приходиться нелегко для обеспечения порядка сборки, Вы эффективно повторно реализуете логику, которую система сборки была сделана решить во-первых. Построение, надежное рекурсивный, делает системы сборки, очень твердо. Реальные проекты имеют много взаимозависимых частей, порядок сборки которых нетривиален для выяснения и таким образом, эту задачу нужно оставить системе сборки. Однако это может только разрешить, что проблема, если это имеет глобальное знание системы.

, Кроме того, рекурсивный делают системы сборки, являются склонными для разваливаний при создании одновременно на нескольких процессорах/ядрах. В то время как эти системы сборки, может казаться, работают надежно над единственным процессором, много недостающих зависимостей идут необнаруженные, пока Вы не начинаете разрабатывать свой проект параллельно. Я работал с рекурсивным, делают систему сборки, которая продолжила работать до четырех процессоров, но внезапно отказала на машине с двумя квадратическими ядрами. Затем я сталкивался с другой проблемой: Эти проблемы параллелизма почти невозможны для отладки, и я закончил тем, что рисовал блок-схему целой системы для выяснения то, что пошло не так, как надо.

Для возвращения к вопросу мне трудно думать о серьезных основаниях, почему каждый хочет использовать рекурсивный, делают. Производительность во время выполнения нерекурсивного GNU Делает системы сборки, твердо биться и, вполне обратное, многие рекурсивные заставляют системы иметь серьезные проблемы производительности (слабая параллельная поддержка сборки является снова частью проблемы). Существует бумага , в котором я оценил (рекурсивное) определенное, Делают систему сборки и сравнил его с портом SCons. Результаты проверки производительности не являются представительными, потому что система сборки была очень нестандартна, но в данном случае порт SCons был на самом деле быстрее.

Нижняя строка: Если Вы действительно хотите использовать, Делают для управления сборками программного обеспечения, пойдите для нерекурсивного, Делают, потому что это делает жизнь намного легче в конечном счете. Лично, я использовал бы SCons по причинам удобства использования (или Грабли - в основном любая система сборки с помощью современного языка сценариев и который имеет неявную поддержку зависимости).

Я предпринял нерешительную попытку своего предыдущего задания при создании системы сборки (на основе GNU, делают), абсолютно нерекурсивный, но я столкнулся со многими проблемами:

• артефактам (т.е. библиотеки и созданные исполняемые файлы) распространяли их источники по многим каталогам, полагаясь vpath для нахождения их
• , Несколько исходных файлов с тем же именем существовали в различных каталогах
• , Несколько исходных файлов были совместно использованы артефактами, часто компилируемыми с различными флагами компилятора
• , Различные артефакты часто имели различные флаги компилятора, настройки оптимизации, и т.д.

, Одна функция GNU делает, который упрощает нерекурсивное использование, целевые значения переменных :

foo: FOO=banana
bar: FOO=orange

Это означает, что при создании целевого "нечто", $ (НЕЧТО) расширится до "банана", но при создании целевой "панели", $ (НЕЧТО) расширится до "оранжевого".

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

основная недостающая возможность GNU делает необходимыми для поддержки нерекурсивности, то, что этому недостает пространства имен . Целевые переменные могут ограниченным способом использоваться для "моделирования" пространств имен, но в чем Вы действительно нуждались бы, должен смочь включать Make-файл в подкаталог с помощью локального объема.

РЕДАКТИРОВАНИЕ: Другой очень полезный (и часто недогруженный) функция GNU делает в этом контексте, средства макрорасширения (см. оценка функция, например). Это очень полезно, когда у Вас есть несколько целей, которые имеют подобные правила/цели, но отличаются способами, которых нельзя выразить с помощью регулярного GNU, делают синтаксис.

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

В настоящее время я работаю над небольшим исследовательским проектом, в котором экспериментирую с непрерывной интеграцией; автоматический модульный тест на ПК, а затем запуск системного теста на (встроенной) цели. Это нетривиально для make, и я искал хорошее решение. Обнаружив, что make по-прежнему является хорошим выбором для переносимых мультиплатформенных сборок, я наконец нашел хорошую отправную точку в http://code.google.com/p/nonrec-make

. Это было настоящим облегчением. Теперь мои make-файлы

• очень просто изменить (даже с ограниченными знаниями make)
• быстро скомпилировать
• , полностью проверяя (.

После прочтения статьи RMCH я поставил перед собой цель написать правильный нерекурсивный Makefile для небольшого проекта, над которым я работал в то время. После того, как я закончил, я понял, что должно быть возможно создать общую «структуру» Makefile, которую можно использовать, чтобы очень просто и кратко сказать make, какие конечные цели вы хотите создать, какие они цели (например, библиотеки или исполняемые файлы ) и какие исходные файлы должны быть скомпилированы для их создания.

После нескольких итераций я в конечном итоге создал именно это: единый шаблонный Makefile, состоящий примерно из 150 строк синтаксиса GNU Make, который никогда не нуждается в модификации - он просто работает для любого типа проекта, в котором я хочу его использовать, и достаточно гибок, чтобы создавать несколько целей разных типов с достаточной степенью детализации, чтобы указать точные флаги компиляции для каждого исходного файла (если я хочу) и точные флаги компоновщика для каждого исполняемого файла. Для каждого проекта все, что мне нужно сделать, это предоставить ему небольшие отдельные файлы Makefile, которые содержат биты, подобные этому:

TARGET := foo

TGT_LDLIBS := -lbar

SOURCES := foo.c baz.cpp

SRC_CFLAGS   := -std=c99
SRC_CXXFLAGS := -fstrict-aliasing
SRC_INCDIRS  := inc /usr/local/include/bar

Makefile проекта, подобный приведенному выше, будет делать именно то, что вы ожидаете: создать исполняемый файл с именем "foo" , компилируя foo.c (с CFLAGS = -std = c99) и baz.cpp (с CXXFLAGS = -fstrict-aliasing) и добавляя "./inc" и "/ usr / local / include / bar" в #include путь поиска с окончательной компоновкой, включая библиотеку "libbar". Он также заметил бы, что существует исходный файл C ++ и известно, что нужно использовать компоновщик C ++ вместо компоновщика C. Фреймворк позволяет мне указать намного больше, чем показано здесь в этом простом примере.

Шаблонный файл Makefile выполняет все построение правил и автоматическое создание зависимостей, необходимых для построения указанных целей. Все файлы, созданные при сборке, помещаются в отдельную иерархию выходных каталогов, поэтому они не смешиваются с исходными файлами (и это делается без использования VPATH, поэтому нет проблем с наличием нескольких исходных файлов с одинаковыми именами).

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

• Это быстро . Он может практически мгновенно определить, что что-то устарело.
• 100% надежные зависимости. Нет никакой вероятности, что параллельная сборка загадочным образом сломается, и она всегда строит ровно минимум, необходимый для обновления всего.
• Мне никогда не придется переписывать снова полный make-файл: D

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

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

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