Пожалуйста

Этого в планах нет. Была задача сформировать такой makefile, чтобы потом про него забыть и никогда не вспоминать, но чтобы при копировании в папку с новым проектом все .c файлы компилировались и собирались в исполняемый файл. Может эта тема и заинетесует, но многообразие утилит для сборки и тестирования пока что только огорчает, так как попытки собрать проект из исходников напоминют ситуацию, когда ты заказал табурет, и мастер уже забивает последний гвоздь и вдруг говорит: "для двух последних ударов нужен молоток Х". Отвечаешь: "у меня такого нет, но есть Y и он вполне способен решить эту задачу". А мастер в ответ выдергивает гвоздь, разламывает всю табуретку и уходит. Стоит тебе через время найти этот X, как мастер заявлает, что тот уже старый и нужен "X 5.0", и вообще, половина досок уже "deprecated"

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

@@tripledistillation1755 например, в Вашем примере не указаны зависимости от my_lib.h

Для компилятора обычно указывают место хранения дополнительных заголовочных файлов. Делается это опцией -I Но здесь это не требуется, поскольку заголовочный там же, где исходник. Поэтому, к стати, заголовочный указан не в угловых скобках, а в ковычках

Возможно. Но gcc компонует исполняемый файл из набора модулей (.o), поэтому они присутствуют в зависимостях. Получение файлов (.o) - это тоже набор целей Makefile-а, для достижения которых нужны соответствующие исходники (.c). А вот какие заголовочные файлы использовать для компиляции исходников, указано в самих исходниках

@@tripledistillation1755 Да, но вот если в проекте поменять .h, но не менять ничего другого - модули не перекомпилируются

Предлагайте свой вариант, будет интересно

TARGET = MyProject CC = gcc PREF_SRC = ./src/ PREF_OBJ = ./obj/ SRC = $(shell find . -name "*.c") OBJ = $(patsubst $(PREF_SRC)%.c, $(PREF_OBJ)%.o, $(SRC)) $(TARGET) : $(OBJ) $(CC) $(OBJ) -o $(TARGET) $(PREF_OBJ)%.o : $(PREF_SRC)%.c mkdir -p $(dir $@) $(CC) -c $< -o $@ clean : rm $(TARGET) $(OBJ) Разница в том, что в переменой SRC список всех файлов, оканчивающихся на ".c", в том числе и в подкатологах внутри src. Команда shell позволяет выполнить команду оболочки и получить результат в виде строки. Далее заменяем префикс "./src/" на "./obj/", а так же расширение ".c" на ".o" с помощью команды patsubst во всех найденных именах файлов исходников. Таким образом, структура папок внутри "./obj/" предполагается такой же, как и в "./src/", но компилятор не будет создавать недостающие папки автоматически по относительному пути файла в "./obj/". Чтобы решить эту проблему, в правило компиляции отдельного исходника добавлена команда mkdir -p $(dir $@). Здесь $@ - это имя файла-цели, то есть файла ".o". dir позволяет выделить из этого имени имя католога, а ключ -p блокирует ошибку, если католог уже существует.

Да, есть над чем подумать. Для заголовочных файлов можно добавить место поиска с помощью опции -I. Makefile очень часто бывает результатом работы скрипта "configure" в случае Linux. Поэтому имеет смысл этот скрипт разобрать. Ещё подкинули вопрос насчет изменения содержимого .h файлов - мол, нужно добавить зависимость. Тут гайд скорее ситуационный: мне нужно было решить конкретную задачу - вот решил до определенной степени и поделился)

Можно. Если вопрос касается материала или чего-то смежного, то задавайте его здесь

Тогда огородом будет main(), из за каждого там изменения все инклюды компилируй по 100 раз. Может откомпилировать их и больше не трогать никогда?

@@vitlevanskiy зависит от IDE. Visual studio сама умеет находить .c файлы по имени h файла в правильной папке и повторно не компилирует если нет изменений.

Тут видео в принципе не рассчитано на такой способ просмотра, но подумаю

Приведите конкретный пример

@@tripledistillation1755 , прошу прощения. Например для создания библиотеки, мы используем .h, и если изменить этот хедер файл, то нужно будет пересобирать все .c файлы, зависимые от него. Спасибо за видео!

Верно. Спасибо за комментарий

@You Tube если не получается забить гвоздь молотком, это еще не значит, что молоток плохой)))

Если вместо " $(PREF_OBJ)%.o: $(PREF_SRC)%.c " использовать " $(OBJ): $(SRC) ", то Make может неправильно сопоставить имена исходников и объектных файлов. Таким образом, при компиляции main.c объектный код может быть отправлен в my_lib.obj, например.

@@tripledistillation1755 я попытался подставить готовые списки. Мэйк безошибочно перебирает список зависимостей по порядку, но почему-то подставляет в каждой команде только первое значение из списка целей (адресовал через $^). При подстановке корня то же правило работает чётко. Видимо, только так.

@@MECHANISMUS да, я столкнулся с такой же проблемой, пытаясь проверить предложенный Вами вариант. Спасибо за обратную связь и рассмотренный случай

@@MECHANISMUS у меня тоже самое, только верно перебирает список целей и в каждой команде подставляет первый аргумент из зависимостей. Как решить понятия не имею. Метод из видео выдает ошибку, что нет правила для сборки объектников, хотя указано все точно так же.

Если бы)

Можно поместить их в "src", а в Makefile-е заменить все вхождения ".c" на ".cpp"

А разработчики make-а в курсе?)

В том, что в make есть механизм " : " А это удобно в случае сборки проекта. Можно относительно просто выстроить дерево зависимостей. Такая задача наверняка решаема в bash, но, может быть, с большими усилиями. Но это то, как я себе представляю ситуацию. А вообще, make - это утилита, то есть средство, а не цель. Средства могут быть разными, зацикливаться на них не следует

@@tripledistillation1755 да, досмотрел видос до конца, немного поюзал, удобнее, чем могло бы быть с башем)