В своей разработке (прежде всего C ++) я давно придерживался использования сборок вне исходного кода. То есть, мой источник , как правило , находится в /project/src
директории и строит жить в /project/build/bin/release
, /project/build/bin/debug
каталоги. Я сделал это, потому что он сохраняет мои исходные каталоги чистыми от промежуточных файлов, у меня есть одно расположение для всех моих двоичных файлов, упаковка проще, очистка проще, а контроль версий проще. (Я что-то пропустил?)
Теперь я наследую (большой) проект, который использует сборки из исходного кода. Какова мотивация для этого типа структуры и каковы ее преимущества? (Меня больше всего волнуют причины инженерного уровня или типы личных предпочтений.)
Я надеялся, что «Разработка крупномасштабного программного обеспечения C ++» Лакоса взвесит это, но я пропустил это, если бы это произошло.
/project/src/bin/release
или действительно все промежуточные и выходные файлы в/project/src
? Последний может быть действительно беспорядком, если есть более дюжины исходных файлов, с первым все в порядке.main.cpp
изначально находясь на верхнем уровне вашего проекта, он по-прежнему создает отдельный каталог сборки cmake вдали от вашего источника на этом верхнем уровне. Я считаю, что MSVS похожа на Клиона и в этом отношении.Ответы:
Спросив сообщество здесь и продолжив поиск в Интернете, я не смог найти существенного технического обоснования для использования сборок из исходного кода. (Есть много примеров причин, чтобы избежать их.)
Единственная объективная причина, которую я обнаружил (как упоминается в комментарии @BartvanIngenSchenau), заключается в том, что сборки в исходном коде иногда по умолчанию используются системой сборки. Из-за этого значения по умолчанию они не требуют затрат времени на настройку, что может быть вполне приемлемо для очень маленького (или начального) проекта.
источник