История изменений

Но у меня есть сомнения что будет так уж просто написать корректную пересборку всего на основе замены target. В смысле чтобы не только в другой каталог собирало но и перекомпилировало все объектники.

Не, тут проблемы не будет. Объектники тоже будут в другом каталоге лежать, же.

Опять куча дублирования строчек наверно получится.

Дублирования тут вообще не будет.

Мэйк же на время создания файлов смотрит,а оно при замене target не меняется.

Так сами файлы меняются. Один вызов билдит main.c в build/debug/main.o, второй вызов в build/release/main.o.

К тому же бОльшим неудобством чем вызов мне кажется сборка debug и release в разные подкаталоги. А не так чтобы зависимо от параметра вызова получать файл с одним и тем же именем на одном и том же месте,но собранный по-разному.

Я не придумал, как это можно сделать нормально.

В целом такие варианты думал:

1. Писать название конфигурации в какой-то служебный файл, например build/configuration. Причём не просто так, а только если он не существует или его содержимое не совпадает с ожидаемым. Т.е. в первый раз написали make debug, создался build/configuration.txt. Во второй раз написали - он не изменился. В третий раз написали make release - он изменился. И поставить этот файл в зависимость ко всем объектникам. Тогда пересоберутся.

2. С помощью линкер скрипта и дефайнов сделать так, чтобы при попытке линковки объектников, собранных в дебаге, в релизный бинарник оно не линковало, и наоборот. Т.е. надо делать make clean перед пересборкой с другой конфигурацией.

Оба варианта выглядят, как гемор. А если ничего не делать - то слишком легко получить странный билд, собрав объектники с дебагом, а потом дёрнув make release и не заметив этого.

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

Но у меня есть сомнения что будет так уж просто написать корректную пересборку всего на основе замены target. В смысле чтобы не только в другой каталог собирало но и перекомпилировало все объектники.

Не, тут проблемы не будет. Объектники тоже будут в другом каталоге лежать, же.

Опять куча дублирования строчек наверно получится.

Дублирования тут вообще не будет.

Мэйк же на время создания файлов смотрит,а оно при замене target не меняется.

Так сами файлы меняются. Один вызов билдит main.c в build/debug/main.o, второй вызов в build/release/main.o.

К тому же бОльшим неудобством чем вызов мне кажется сборка debug и release в разные подкаталоги. А не так чтобы зависимо от параметра вызова получать файл с одним и тем же именем на одном и том же месте,но собранный по-разному.

Я не придумал, как это можно сделать нормально.

В целом такие варианты думал:

1. Писать название конфигурации в какой-то служебный файл, например build/configuration. Причём не просто так, а только если он не существует или его содержимое не совпадает с ожидаемым. Т.е. в первый раз написали make debug, создался build/configuration.txt. Во второй раз написали - он не изменился. В третий раз написали make release - он изменился. И поставить этот файл в зависимость ко всем объектникам. Тогда пересоберутся.

2. С помощью линкер скрипта и дефайнов сделать так, чтобы при попытке линковки объектников, собранных в дебаге, в релизный бинарник оно не линковало, и наоборот. Т.е. надо делать make clean перед пересборкой с другой конфигурацией.

Оба варианта выглядят, как гемор. А если ничего не делать - то слишком легко получить странный билд, собрав объектники с дебагом, а потом дёрнув make release и не заметив этого.

А так я проблем не вижу с тем, что разные билды лежат в разных каталогах. Лежат и лежат. Даже где-то может быть удобно. Места особо не занимают всё равно.