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

Так-с. Ну в целом можно сказать попробовал.

1. Вместо заморочек с доп. правилами .d0 –> .d, тупо редактирую .d inplace в том же правиле где вызываю gcc, следующей же командой после вызова gcc.

2. При редактировании .d восстанавливаю его mtime: stat() отдаёт наносекунды, utimes() берёт микросекунды, я округляю вниз (ns - 999) / 1000, т.к. .o зависит от .d и если mtime(.d) > mtime(.o) то получается постоянная пересборка.

3. .c++m упоминается в .d гораздо чаще чем я думал: в .d-файле самого модуля там накручено дохрена, в т.ч. правило «.c++m : .gcm» без wildcards (т.е. маппер таки-применён; и самому это правило химичить не нужно, .SECONDEXPANSION тоже не нужен). Я вычищаю вообще все упоминания «.c++m».

4. Я делал makefile по руководству http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/, но для модулей оно сбоит: если после make clean исходник A, импортирующий модуль, начинает компиляться раньше/одновременно исходника B, экспортирующего модуль, то т.к. файла A.d ещё нет (по ссылке этот файл генерится не отдельным правилом, а одновременно с .o), то компиляция A падает т.к. модуль B не найден. Без модулей (т.е. с инклудами) это руководство работает т.к. инклуды изначально лежат в src, независимо от порядка сборки. Возможно, придётся возвращаться к классическому подходу: разные правила для .o и .d.

Так-с. Ну в целом можно сказать попробовал.

1. Вместо заморочек с доп. правилами .d0 –> .d, тупо редактирую .d inplace в том же правиле где вызываю gcc, следующей же командой после вызова gcc.

2. При редактировании .d восстанавливаю его mtime: stat() отдаёт наносекунды, utimes() микросекунды, я округляю вниз (ns - 999) / 1000, т.к. .o зависит от .d и если mtime(.d) > mtime(.o) то получается постоянная пересборка.

3. .c++m упоминается в .d гораздо чаще чем я думал: в .d-файле самого модуля там накручено дохрена, в т.ч. правило «.c++m : .gcm» без wildcards (т.е. маппер таки-применён; и самому это правило химичить не нужно, .SECONDEXPANSION тоже не нужен). Я вычищаю вообще все упоминания «.c++m».

4. Я делал makefile по руководству http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/, но для модулей оно сбоит: если после make clean исходник A, импортирующий модуль, начинает компиляться раньше/одновременно исходника B, экспортирующего модуль, то т.к. файла A.d ещё нет (по ссылке этот файл генерится не отдельным правилом, а одновременно с .o), то компиляция A падает т.к. модуль B не найден. Без модулей (т.е. с инклудами) это руководство работает т.к. инклуды изначально лежат в src, независимо от порядка сборки. Возможно, придётся возвращаться к классическому подходу: разные правила для .o и .d.

Так-с. Ну в целом можно сказать попробовал.

1. Вместо заморочек с доп. правилами .d0 –> .d, тупо редактирую .d inplace в том же правиле где вызываю gcc, следующей же командой после вызова gcc.

2. При редактировании .d восстанавливаю его mtime: stat() отдаёт наносекунды, utimes() микросекунды, я округляю вниз (ns - 999) / 1000, т.к. .o зависит от .d и если mtime(.d) > mtime(.o) то получается постоянная пересборка.

3. .c++m упоминается в .d гораздо чаще чем я думал: в .d-файле самого модуля там накручено дохрена, в т.ч. правило «.c++m : .gcm» без wildcards (т.е. маппер таки-применён; и самому это правило химичить не нужно, .SECONDEXPANSION тоже не нужен). Я вычищаю вообще все упоминания «.c++m».

4. Я делал makefile по руководству http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/, но для модулей оно сбоит: если после make clean исходник A, импортирующий модуль, начинает компиляться раньше/одновременно исходника B, экспортирующего модуль, то т.к. файла B.d ещё нет (по ссылке этот файл генерится не отдельным правилом, а одновременно с .o), то компиляция B падает т.к. модуль A не найден. Без модулей (т.е. с инклудами) это руководство работает т.к. инклуды изначально лежат в src, независимо от порядка сборки. Возможно, придётся возвращаться к классическому подходу: разные правила для .o и .d.