Нет правил для создания target consoleio.c

Question

В недавнем выпуске я обнаружил, что DJGPP может принимать только ограничение на количество символов в командной строке DOS. Чтобы обойти это ограничение, я решил попробовать написать make-файл, чтобы позволить мне передавать более длинные строки . В процессе взлома make-файла и его тестирования я натолкнулся на странную ошибку. Makefile выглядит следующим образом:

AS  :=  nasm
CC  :=  gcc
LD  :=  ld

TARGET      :=  $(shell basename $(CURDIR))
BUILD       :=  build
SOURCES     :=  source

CFLAGS  :=  -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions \
            -nostdinc -fno-builtin -I./include
ASFLAGS :=  -f aout

export OUTPUT   :=  $(CURDIR)/$(TARGET)

CFILES      :=  $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.c)))
SFILES      :=  $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.s)))

SOBJS   :=  $(SFILES:.s=.o)
COBJS   :=  $(CFILES:.c=.o)
OBJS    :=  $(SOBJS) $(COBJS)

build   :   $(TARGET).img

$(TARGET).img   :   $(TARGET).bin
    concat.py

$(TARGET).bin   :   $(OBJS)
    $(LD) -T link.ld -o $@ $^

$(SOBJS)    :   %.o :   %.asm
    $(AS) $(ASFLAGS) $< -o $@

$(COBJS)    :   %.o :   %.c
    $(CC) -c $< $(CFLAGS) -o $@

При попытке запустить я получаю эту ошибку:

make: *** No rule to make target `consoleio.c', needed by `consoleio.o'.  Stop.

Чего я не понимаю, так это того, почему он пытается найти правило для файлов .c. Из того, что я понимаю, если файл есть, он должен просто использовать его. Как сделать так, чтобы make не нуждался в правиле для файлов .c?

Answer 1

То, что вы пытаетесь сделать, не будет работать без VPATH, и, поскольку вы все еще изучаете make-файлы, я бы избегал использования VPATH.

Правило ищет "consoleio.c", который, если я правильно понял, ваш make-файл не существует; то, что существует, является "source / consoleio.c". Вы, вероятно, должны изменить его на что-то вроде «$ (SOURCES) /%. C» вместо «% c».

Однако я не проверял ваш синтаксис для этого правила. Если он неправильный, вместо него будет использовано встроенное правило «% .o:% .c», что приведет к той же проблеме.

Однако то, что ты делаешь, не совсем то, что я видел. Обычный способ:

• Создайте неявное правило "% .o:% .c" (или в вашем случае "% .o: $ (SOURCES) /%. C")
• Явный список зависимостей для каждого файла: "foo.o: foo.c bar.h baz.h" (без команды, неявное правило имеет команду)

Answer 2

@ CesarB, похоже, прибил проблему, я просто добавлю пару замечаний.

1. Я бы настоятельно рекомендовал не использовать подстановочные знаки в правилах сборки. Правила сборки должны четко определять, что именно собирается, и не зависеть от того, какие файлы находятся в каталоге.

2. Я бы также рекомендовал не использовать VPATH, если вы (1) не собираете отдельный каталог для сборки или (2) ваши исходные файлы не распределены по большому количеству каталогов. Если все ваши источники находятся в одном каталоге, использование VPATH только приведет к путанице.

3. Форма назначения: = обычно используется только тогда, когда известно, что оценка переменной занимает много времени, например, при использовании $ (shell ...). В противном случае «=» предпочтительнее.

4. Использование «export» для распространения OUTDIR в concat.py (что, как я полагаю, так как concat.py не принимает никаких параметров) является запахом кода. Если возможно, передайте его в качестве параметра.

Answer 3

Давайте попробуем ответить без комментариев ...

Возможность A:

• Ваш макрос для SFILES ищет файлы, заканчивающиеся на '.s'.
• Ваше правило для компиляции SOBJS ищет файлы, заканчивающиеся на '.asm'.

Возможность B:

• Ваше правило для SOBJS и COBJS указано в нотации, которую я не узнаю.

• Согласно руководству GNU Make, вы можете писать неявные правила как:

  %. O:% .c; Команда

У вас, кажется, есть список целей $ (SOBJS), который зависит от '%.o : %.asm'. Я не уверен, как make это интерпретирует.

Лично я бы не стал доверять шаблонам в правилах сборки. Я бы предпочел потратить время, перечисляя, какие именно исходные файлы необходимы для создания кода. В результате я не часто сталкиваюсь с этой проблемой.