GNU Make может больше чем ты думаешь

[@dohlik]

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

ЗЫ «ньюансы» стали уже фишкой Хабра наверное

[@redchrom]

Я не люблю русский язык, в школе любовь отбили.

[@dohlik]

Ну, мне (и Вам, судя по всему) почему-то школьная информатика не отбила интереса к ИТ ;)

[@redchrom]

Наверное по тому, что информатику не вели gramar nazi.

[@dals]

Какбе «gramMar nazi».

[@ilya_ost]

You is one of them!

[@gearss]

Какбы «You ARE one of them!» :)

[@ilya_ost]

Да я знаю. Как бы шутка. И, кстати, КАК БЫ.

[@gearss]

Я вас отлично понял (с первого раза) и поддержал.
Мне вообще следовало написать «какбе», подражая <~dals>

[@Holy_Cheater]

Если вам без слова «как бы»,
обойтись никак нельзя,
то умом вы значит слабы
и учились как бы зря.
(ц) не помню кто :)

[@redchrom]

В первую очередь конечно спортивный интерес. Практическая польза: иметь заготовку для небольших программ, где лень возиться в autotools.

[@vilgeforce]

Я для мелочи юзаю qmake. Создает make-файл, которым и пользуюсь :-)

[@redchrom]

Если бы я работал с Qt то тоже наверное бы пользовал.

[@lostdj]

Qt и не нужно, чтобы использовать qmake standalone.

[@stoune]

А не проще и практичнее чем тратить время на бодание с граблями make делать сборку с помощью scons, а секономленное время потратить на разработку.
Проблемы make извесны и в рамках его идеологии и архитектуры неизлечимы(иначе порушится обратная совместимость) так может тогда выбрать инструмент который будет помагать, а не ставить подножки.

[@redchrom]

Нарисовалась свободная минутка, имею право потратить так как хочу, кто-то в игры играет, кто-то в курилке тусит, а я с gnu make поковырялся.

[@strem]

Исправьте, пожалуйста:

[@strem]

В мире unix (с под*о*чи gnu)

[@redchrom]

Поправил, спасибо.

[@strem]

Прошу прощения — какие-то непонятные явления у меня с комментариями. Виноват.

[@kmmbvnr]

Статью Эффективное использование GNU Make читали?

[@redchrom]

Нет, но спасибо, почитаю.

[@Yfka]

Для большинства достаточно крупных проектов используются именно Мэйкфайлы, а не autotools, причём написанные людями Мэйкфайлы. Это хорошо ложится в практику ежедневных билдов.

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

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

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

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

Тем кто планирует писать немаленькие программы/системы настоятельно рекомендую обратить внимание на Ant.

[@redchrom]

Хм, а я думал им только яву собирать. Нодо будит посмотреть.

[@markshevchenko]

Тот самый случай, когда комментарий оказался информативнее статьи. :)

А в общем, даже странно, что люди не слышали про make. Все C/C++ компиляторы, не только под GNU/Linux и Windows, а вообще все, идут с тем или иным вариантом make. И появился он тогда же, когда C и UNIX.

И, хоть в этом я не уверен, почти наверняка этот, известный нам make, является переложением другой тулзы, которая существовала ещё до UNIX.

Да, и добавлю, раз уж речь зашла. Аналогом Ant в мире .NET является утилита MS Build.

[@shai_xylyd]

Аналогом Ant в мире .NET является NAnt=)

[@stoune]

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

А для личных маленьких проэктов я использую scons. XML-хорош для машины но для человека он ужасен. Человекочитабельный формат значительно легче в дальнейшем сопровождать, да и после обучения легче логическую ошибку найти.

[@redchrom]

xml уныл и для машины, s-expressions рулит.

[@Frosty]

Было бы интересно, если бы кто нибудь написал обзор о том, как можно собирать с помощью make на N ядрах одновременно. Хотя, думаю это не так то и просто, раскидать N исходников на N ядер с учетом зависимостей и очередности сборки.

[@redchrom]

make -j4

[@redchrom]

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

[@Frosty]

Встроенная возможность 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

[@tass]

-j без параметра АФАИР это количество используемых потоков = количество ядер+1

[@Frosty]

что количество потоков вроде как равно количеству ядер, но для чего +1?

[@ptiss]

например для того, чтобы n+1й работал, когда n-й пишет на диск. чисто теоретически.

[@alex3d]

хм, мой 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


[@AlexcYeCu]

сборке опасносте?

[@walker]

>можно хакнуть Makefile

т.е. теперь чтение документации называется хаком?

[@Frosty]

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

[@walker]

не совсем очевидным? о_О

это именно стандартное поведение make, и я удивился, когда прочел, что автор писал все зависимости руками.

[@redchrom]

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

[@walker]

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

а так, словно из журнала хакер…

[@redchrom]

Ок, убрал. Всё-таки в англоизычных интернетах как-то более классически это слово воспринемают :\

[@walker]

здорово, что прислушиваешься к мнению других. :)

[@redchrom]

Можешь провести аналогию с «грязный хак» — воткнуть костыль чтобы работало. В данном контексте примерно тоже самое.

[@grep0]

Кстати, есть более стандартный способ не гадить в директории с сорцами — VPATH

[@redchrom]

Да, спасибо за совет. Как-то работал над проектом, где была куче сорцов в одной дире и несколько директорий для сборки (собирались разные проекты на одном ядре). Т.е. там нельзя было все .o держать в одном месте и Makefile генерился своим скриптом. Если занесёт на подобную организацию сборки — обязательно VPATH заюзаю.

[@optio]

Когда передо мной встал выбор какую систему сборки использовать — я остановился на scons. К тому моменту я неплохо владел make и в ужасе думал о сложном Makefile под большой проект: слишком много нужно прописать руками, слишком нечеловеческий синтаксис для простых операций.
Я ценю шелл-скрипт, но

%.o: %.c defines.h
             $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<

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

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

[@redchrom]

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

[@optio]

Зависимость файлов от defines.h сама сгенерится. Генерацию зависимостей таки придётся ручками прописывать: $(CC) -M и всё такое… :)

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

[@nuit]

-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 файлики и делаю инклуд в основной). Если нужно будет что-то посложнее — всё легко реализуется.

[@parta]

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

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

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

[@VolCh]

Офтоп: что лучше Windows или Linux? Третьего не дано :)

[@redchrom]

Бздун такой бздун.

[@maashaa]

>> опыт работы с GNU Make, дал мне понять, что при желании, на ней можно сделать полноценную билд систему

Мой работы с C++ и Java дал мне понять, что при желании, на них можно полноценно программировать. :-)

[@aabzel]

Как сделать подсветку #ifdef(ов) в eclipse если сборка происходит из самописных Make?

[@aabzel]

Как генерировать зависимости между программным компонентами через graphviz используя Make?