Журнал Пушыстого

Модификаторы для глобальных переменных:
constexpr - для выражений вычислимых в compile-time отдельного модуля
linkexpr - для выражений вычислимых при полной сборке системы
deployexpr - для выражений вычислимых при инсталляции системы
rebootexpr - для выражений вычислимых при старте хоста
initexpr - для выражений вычислимых при старте программы
expr<component> - для выражений вычислимых при запуске определённого под-компонента системы. Топологическая сортировка по зависимостям.

Такая разбивка позволяет разным фазам сборки-деплоя-запуска-интерпретации понимать, какие выражения обязаны быть уже вычислены, и не пытаться вычислять их динамически.
А так же отлавливать ошибки в тех случаях, когда программист пытается вычислить linkexpr через rebootexpr

Мысли по поводу того, как убрать мистическое знание программиста "а теперь необходимо сделать clean + full rebuild" и записать его в makefile (не важно, какого конкретно из make).

Устанавливать makefile целиком как зависимость для перекомпиляции проекта целиком - нехорошо, так как он автогенерится, и от убранного import/include его содержимое изменится. Но с другой стороны, изменение команды компиляции - это уже повод пересобрать все ноды где эта команда используется.
Значит, зависимости надо хранить отдельно, и их изменение - не вызывает full rebuild. А вот команды компиляции - надо добавить в зависимости всех нод которые их вызывают.

Например, вместо:

foobar.obj: foobar.cpp
   compiler -c foobar.cpp -o foobar.obj -some-compiler-flag1 -some-compiler-flag2 

писать makefile как-то так:

foobar.obj: foobar.cpp compile.sh # compile.sh тоже в зависимостях этой ноды
   compile.sh foobar.cpp -o foobar.obj

compile.sh: env.COMPILER_PATH.txt # compile.sh зависит от переменной окружения COMPILER_PATH

env.INCLUDE.txt:
     echo $COMPILER_PATH> env.COMPILER_PATH.txt

По хорошему, compile.sh так же должен зависеть от всех файлов в системе которые влияют на его работу. Например, изменение системной версии gcc после apt-get dist-updgrade - это повод пересобрать проект.

Могут быть ещё дополнительные зависимости, например от переменных окружения. Такие переменные окружения можно распечатать в файл и тоже поставить как зависимости в makefile

( так же отдельно надо думать о том, что бы убивать файлы без родителей, и о том как детектить "файл изменился", см. тег "build" ).

Какие системы сборки умеют корректно удалять результирующие файлы, для которых уже нет источников? Без clean && rebuild-all, а оставляя билд инкрементальным.

maven явно пишет в документации, что не умеет корректно определять что jar надо перепаковать, и поэтому пакует всегда. Наверное, потому что на Java так сложно сравнить равны ли два списка, и потому что сборку java->class перепоручает javac который не умеет удалять .class для которых нет исходников. Зачем тогда называться сборщиком, если перепоручаешь сборку другому посредственному сборщику, у которого прямая обязанность - компиляция, а не инкрементальная сборка.

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

Если "make" != "make clean; make", то от такого make у меня батхёрт.

maven-archiver: Checking for timestamps will offer a performance gain on the cost that you get inaccurate results from time to time. In particular, removal of source files won't be detected.

От билд-системы хочется, что бы она проверяла необходимость билда не перечислением всех файлов, а просто по нотификациям от файловой системы (если это мой локальный жесткий диск).
Иначе странно, что мне приходится руками отключать отдельные элементы, так как проверка что ничего не изменилось идёт 40 секунд. Я ТОЧНО ЗНАЮ ЧТО Я НЕ МЕНЯЛ ИСХОДНИКИ тех 50 проектов, к которым не имею отношения, почему билд система этого не может знать.
Например, некто точно знает, что версия gcc/javac/make у него меняется раз в полгода, поэтому проверку изменения бинарников компиляторов и системных библиотек в make не вставляет. А можно было бы, если бы такая проверка срабатывала мгновенно.

Что интересно, strong exception safety из C++ мне гораздо важнее во всяких .bat/.py скриптах, чем в С++.

Типично С++ (в моём случае) портит только память процесса, а скрипты типично портят файловую систему, html-страницы и тп., их восстановить обратно с середины бывает очень сложно.

Отсюда - когда надо сложным образом обработать файлы, сначала я их кладу в temp-папку, и когда уже всё завершено - можно положить их обратно (скопировать поверх или rename + unlink старой копии).

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

Дзен отладки от kunaifusu :)