Точно? Где там в основном make-файле зависимость основных .c от .h-файлов во вложенных проектах?

Я не вижу:
https://tvoygit.ru/stein47/russian-virt … le.am#L200

Отредактировано Лис (2023-03-14 00:02:50)

Наверное надо дописать?

А всякие опции типа -j1 и установку переменной CC=
стереть...

Значит надо прописать зависимость сразу от цели по сборке всех дочерних подпроектов.

Нет. Надо определить .PHONE цель
и в сборку .o-файлов добавить её как одну из зависимостей.

Тогда перед любой компиляцией любого .c файла из основного проекта сначала будут выполняться вызовы команды make для всех подпроектов.

то есть, вместо строки 200
$(OBJDIR)%.o : $(SRCDIR)%.c

написать
$(OBJDIR)%.o : subsystem $(SRCDIR)%.c

Отредактировано Лис (2023-03-14 00:50:04)

Неверно, что правая часть используется, если это был .PHONY target, как я предлагал. Мне так кажется, но проверять это я конечно не буду.

Отредактировано Лис (2023-03-14 09:01:33)

Откуда неуверенность такая. Мы же выяснили причину. Она в том, что не прописана зависимость основных .c-файлов от .h-файлов в поддиректориях.

Но я проверил:

machines/intel64 # make -j4 all




-------- Начало ---------
Русский в C/C++:
sed '1s/^/#line 1 "src_rus\/ansicode.rh"\n/' src_rus/ansicode.rh | sed -f ru-to-c > .src/ansicode.h
Русский в C/C++:
sed '1s/^/#line 1 "src_rus\/debug.rh"\n/' src_rus/debug.rh | sed -f ru-to-c > .src/debug.h
Русский в C/C++:
sed '1s/^/#line 1 "src_rus\/interface.rh"\n/' src_rus/interface.rh | sed -f ru-to-c > .src/interface.h

Русский в C/C++:
sed '1s/^/#line 1 "src_rus\/opcode.rh"\n/' src_rus/opcode.rh | sed -f ru-to-c > .src/opcode.h



Русский в C/C++:
sed '1s/^/#line 1 "src_rus\/vm.rh"\n/' src_rus/vm.rh | sed -f ru-to-c > .src/vm.h
Русский в C/C++:
sed '1s/^/#line 1 "src_rus\/vm_core.rh"\n/' src_rus/vm_core.rh | sed -f ru-to-c > .src/vm_core.h

Русский в C/C++:
sed '1s/^/#line 1 "src_rus\/main.r"\n/' src_rus/main.r |  sed  -f ru-to-c > .src/main.c
Русский в C/C++:
sed '1s/^/#line 1 "src_rus\/vm.r"\n/' src_rus/vm.r |  sed  -f ru-to-c > .src/vm.c


Компиляция C/C++: .src/vm.c
Компиляция C/C++: .src/main.c
gcc -c -Os -Wall -MD -MF bin/.dep/vm.o.d -I./include  -o  bin/obj/vm.o .src/vm.c
gcc -c -Os -Wall -MD -MF bin/.dep/main.o.d -I./include  -o  bin/obj/main.o .src/main.c
src_rus/main.r: В функции «main»:
src_rus/main.r:23:7: предупреждение: переменная «имя_файла» определена, но не используется [-Wunused-but-set-variable]
   23 | симв* имя_файла = NULL;
      |       ^~~~~~~~~

Сборка: proba
gcc  -o proba bin/obj/main.o bin/obj/vm.o

не падает.

Если добавить .h-файлы в цель "$(OUT):",  где вызывается команда $(CC),
а не в цель "build:",
тогда .h-файлы будут собраны до вызова $(СС), потому что
до начала работы сниппета (внутри правила) должны уже существовать .h файлы.

Правило/цель сборки .h файлов обязательно будет выполнена раньше.
То есть до всех параллельных запусков сниппета.
Сниппет цели "$(OUT)" вообще не будет выполняться параллельно, потому что результат сборки/линковки - один файл.
Это будет единственный запуск.

Я думал, что цель "build:" занимается запуском компилятора, но это не так,
вместо этого она только копирует файлы и зависит от цели $(OUT).
Так что да, твоё опасение интересное, и может быть верным.

Можно создать цель по сборке заголовочных файлов,
и добавить её зависимостью в сборку .c-файлов.
Тогда все .h-файлы точно будут генерироваться раньше.
Но это не нужно, так как при дерусификации rc-файлов заголовочные файлы не используются.

Отредактировано Лис (2023-03-14 18:48:23)

Я не увидел противоречий с написанным выше.

Ну да, make не запускает сниппет в тот же момент, как распарсит цель. Ну и что?

Зависимости из правой части всё равно будут отработаны раньше.

Сделай, пожалуйста, в веб-интерфейсе репозитория на tvoygit.ru ветку "devel-mult" веткой по-умолчанию.
Было бы вообще идеально, если бы ты сразу писал SHA1 коммита. Тогда я бы его сразу копировал из сообщения на форуме,
а не лез бы сначала на форум, чтобы посмотреть URL репозитория, затем в репозиторий, чтобы выбрать ветку и скопировать его оттуда.
И на форуме было понятно в будущем, про что идёт речь. Это сейчас коммит последний, а позже станет непонятно, какой был.

Коммит 91fc7dfa63764b763b7690fa50b570d1c1ecb1e8
собирается: