Comments 58
Вы в скриптах тоже допускаете грамматические АшЫПки, или просто не любите русский язык?

ЗЫ «ньюансы» стали уже фишкой Хабра наверное
Ну, мне (и Вам, судя по всему) почему-то школьная информатика не отбила интереса к ИТ ;)
Я вас отлично понял (с первого раза) и поддержал.
Мне вообще следовало написать «какбе», подражая <~dals>
Если вам без слова «как бы»,
обойтись никак нельзя,
то умом вы значит слабы
и учились как бы зря.
(ц) не помню кто :)
Хорошая статья. Правда как то не могу понять её практического применения… Вернее я не могу понять зачем это надо? Если спортивный интерес — однозначно вам плюс. А если нет — раскажите мне, так как любопытно =)
В первую очередь конечно спортивный интерес. Практическая польза: иметь заготовку для небольших программ, где лень возиться в autotools.
А не проще и практичнее чем тратить время на бодание с граблями make делать сборку с помощью scons, а секономленное время потратить на разработку.
Проблемы make извесны и в рамках его идеологии и архитектуры неизлечимы(иначе порушится обратная совместимость) так может тогда выбрать инструмент который будет помагать, а не ставить подножки.
Нарисовалась свободная минутка, имею право потратить так как хочу, кто-то в игры играет, кто-то в курилке тусит, а я с gnu make поковырялся.
Прошу прощения — какие-то непонятные явления у меня с комментариями. Виноват.
Для большинства достаточно крупных проектов используются именно Мэйкфайлы, а не autotools, причём написанные людями Мэйкфайлы. Это хорошо ложится в практику ежедневных билдов.

Вы будете смеяться, но в Windows мэйк используется ещё шире, чем юниксах. 95% известным мне проектов собираются в Виндах с помощью микрософтского nmake.

Но чем сложнее становится проект, тем сложнее становятся Мэйкфайлы. Всё больше уровней включений (include) становится в Мэйкфайлах.

Постепенно, с ростом проекта, поддерка Мэйкфайлов становится всё более и более утомительной, затратной. И тут уже действительно недостатки мэйка становятся видны невооруженным глазом. Но есть другая система, которая написана специально, чтобы преодолеть недостатки мэйка (Особенно зависимости, обслуживание зависимостей). Я говорю об Apache Ant. ant.apache.org/

Да, корни Анта из Жавы, но он применим для сборки систем на любых языках программирования, на любых ОС.

Тем кто планирует писать немаленькие программы/системы настоятельно рекомендую обратить внимание на Ant.
UFO landed and left these words here
Вообще-то для промышленного C/C++ под Windows доминирует Visual C++ и у него своя система MSBuild, но под C++ используется VCBuild, его я считаю использовать целесообразнее в Windows чем Ant. В 2010 планируют польностью перейти к MSBuild без использования VCBuild.

А для личных маленьких проэктов я использую scons. XML-хорош для машины но для человека он ужасен. Человекочитабельный формат значительно легче в дальнейшем сопровождать, да и после обучения легче логическую ошибку найти.
Было бы интересно, если бы кто нибудь написал обзор о том, как можно собирать с помощью make на N ядрах одновременно. Хотя, думаю это не так то и просто, раскидать N исходников на N ядер с учетом зависимостей и очередности сборки.
Это по два трэда на ядро будет. Проблемы встречал только на автотулз, да и то в редких ситуациях.
Встроенная возможность make, отлично! Спасибо!
Протестировал на последней ревизии mplayer-а:
make: real 4m12.391s
make -j4: real 1m17.964s
make -j:real 1m13.463s

Это на Intel® Core(TM)2 Quad CPU Q9550 @ 2.83GHz
-j без параметра АФАИР это количество используемых потоков = количество ядер+1
что количество потоков вроде как равно количеству ядер, но для чего +1?
например для того, чтобы n+1й работал, когда n-й пишет на диск. чисто теоретически.
хм, мой make вот что говорит

$ (make -h 2>&1 && make -v) | grep -e "Make\|-j "
-j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg.
GNU Make 3.81
>можно хакнуть Makefile

т.е. теперь чтение документации называется хаком?
Использование чего либо не совсем очевидным образом и есть хак. Может в этом случае и громковато сказано, но человек проявил терпение и смекалку, за что и получил от меня плюс. Осилить документацию — иногда это тот еще труд :)
не совсем очевидным? о_О

это именно стандартное поведение make, и я удивился, когда прочел, что автор писал все зависимости руками.
А мне например очевидно как использовать find и я про неё статьи не пишу. Если уж задел тебя использованием словом «хак» то извини, обидеть не хотел.
да, ты четко подметил разницу — если убрать из статьи фразу про хак, она воспринимается совсем иначе.

а так, словно из журнала хакер…
Ок, убрал. Всё-таки в англоизычных интернетах как-то более классически это слово воспринемают :\
Можешь провести аналогию с «грязный хак» — воткнуть костыль чтобы работало. В данном контексте примерно тоже самое.
Кстати, есть более стандартный способ не гадить в директории с сорцами — VPATH
Да, спасибо за совет. Как-то работал над проектом, где была куче сорцов в одной дире и несколько директорий для сборки (собирались разные проекты на одном ядре). Т.е. там нельзя было все .o держать в одном месте и Makefile генерился своим скриптом. Если занесёт на подобную организацию сборки — обязательно VPATH заюзаю.
Когда передо мной встал выбор какую систему сборки использовать — я остановился на scons. К тому моменту я неплохо владел make и в ужасе думал о сложном Makefile под большой проект: слишком много нужно прописать руками, слишком нечеловеческий синтаксис для простых операций.
Я ценю шелл-скрипт, но
%.o: %.c defines.h
             $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<

для большого проекта, среди сотен подобных строчек просто снесёт голову…

А в случае со scons мы имеем полноценное python-окружение, внятные директивы и умный сборщик…

scons конечно хорошо но зачем правила то руками писать?
%.o: %.c defines.h
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
— так не нужно. Зависимость файлов от defines.h сама сгенерится. Также для специфичных целей, можно указать специфичные CFLAGS и т.д. Хотя конечно лучше scons использовать, если есть возможность, я просто в защиту make :)
Зависимость файлов от defines.h сама сгенерится. Генерацию зависимостей таки придётся ручками прописывать: $(CC) -M и всё такое… :)

P.S. Я тоже не наезжаю на make, хорошая система. Но стоит использовать более современные аналоги :)
-include .config
-include ../mk/common.mk

all:

dir  := ls
exe  := program
src  := main.c
misc := ls/stdafx.h.gch
src := $(addprefix $(dir)/, $(src))

$(eval $(call make-program, $(exe), $(misc), $(src)))

-include ../mk/build-rules.mk


Вот примерно такие у меня мэйкфайлы для новых проектов.
Все зависимости файлов итп итд сгенерируются(одновременно с компиляцией сишного файла, а не как в этой статье). Можно так же наделать много make-program/library/archive/итд (обычно я их выношу в отдельные .mk файлики и делаю инклуд в основной). Если нужно будет что-то посложнее — всё легко реализуется.
Можно просто, для конкретного бинарика указать список зависимых объектов и он их соберёт


Не поверите, make это умеел еще тогда, когда ни вас, ни GNU в проекте не было.
«В мире unix (с подачи gnu) традиционно используется autotools..» — «мир юникс» не начинается и не заканчивается гнутым подельем.
«Но почему-то ядро Linux собирается при помощи GNU Make, а вся FreeBSD включая порты при помощи BSD Make.» — еще не хватало чтобы бсд собиралась гнутьем.

вы и все гнутье сообщество будете очень удивлены, когда узнаете что все чему вы радовались последние годы существования тазика торвальца и гнутья существует довольно давно за пределами гну. а еще больше удивитесь тому что там, за рамками гнутья, есть такие вещи которых у гнутья попросту нет.

никогда не забуду как линупсятнеги радовались своему LVM'у и даже собрались портировать во FreeBSD. а бсдятники недоуменно пальцем у виска крутили… в конечном счете гнушники не осилили портануть, а потом обиделись когда узнали что в бсд с незапамятных времен есть vinum который умеет все что лвм и еще немного сверху…
>> опыт работы с GNU Make, дал мне понять, что при желании, на ней можно сделать полноценную билд систему

Мой работы с C++ и Java дал мне понять, что при желании, на них можно полноценно программировать. :-)
Only those users with full accounts are able to leave comments. Log in, please.