LINUX.ORG.RU

GNU make 4.0

 ,


0

3

Вышел релиз инфраструктуры систем сборки make от GNU.

Из нововведений:

  • Интеграция guile (1.8/2.0+) в качестве встроенного языка расширений
  • Группирование вывода при рекурсивной параллельной сборке (--оutput-sync)
  • Трассировка в виде принудительного вывод инструкций, даже в случае использования @/.SILENT, вывода файла/строки, в котором этот рецепт определен и устаревших зависимостей (--trace).
  • Принудительное отключение всех отладочных опций (--debug n)
  • Сервер задач и .ONESHELL теперь доступны для Windows порта.
  • Для совместимости с BSD - != эквивалент = $(shell ..). Соответственно нарушена совместимость для случая, когда переменная оканчивается на '!', будьте бдительны.
  • POSIX 2012 эквивалент (:=) — (::=)
  • Новая функция $(file ...) для записи в файл
  • Добавление -r/-R в MAKEFLAGS внутри MakeFile приводит к ожидаемому результату, убирая стандартные рецепты.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Dendy (всего исправлений: 4)

Интеграция guile (1.8/2.0+) в качестве встроенного языка расширений

Почему не Python или Lua?

NaN
()
Ответ на: комментарий от NaN

Потому что GNU. Guile — официальный язык расширений GNU

vasily_pupkin ★★★★★
() автор топика

Соответственно нарушена совместимость для случая, когда переменная оканчивается на '!', будте бдительны.

Поправочка - поведение меняется в случаях, если имя переменной оканчивается на '!', а перед '=' нет пробела:

variable!= foo

Если между именем переменной и оператором присваивания есть пробел, проблем не будет:

variable! = foo

Laz ★★★★★
()

одно добавляем, другое ломаем

kto_tama ★★★★★
()
Ответ на: комментарий от devl547

Это как же? Кучей конструкций вида if ! -f $file then ... fi ? А как быть с шаблонными правилами? Переписать make на шелле несложно, но зачем? Тем более, что у make даже декларативный язык из коробки.

anonymous
()
Ответ на: комментарий от devl547

если его может заменить простой шелл-скрипт

Простой?!?

anonymous
()
Ответ на: комментарий от anonymous

Нужен. Ибо cmake не сам по себе проекты собирает, а только генерирует Makefile, который потом всё равно скармливать в make.

VladimirP ★★★★
()
Ответ на: комментарий от VladimirP

Ибо cmake не сам по себе проекты собирает, а только генерирует Makefile, который потом всё равно скармливать в make.

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

Dendy ★★★★★
()

Группирование вывода при рекурсивной параллельной сборке (--оutput-sync)

Да неужели?

m0rph ★★★★★
()

уберите слово «замечательной». Для таких заявлений должны быть веские основания. Будьте нейтральны в новостях (как wiki)

reprimand ★★★★★
()
Ответ на: комментарий от Reset

что такое ninja ?

Ninja — это правильный Make. С одной стороны язык Makefile недостаточно развит для систем сборки, в то же время дикий синтаксис уже непозволяет писать краткие минималистичные скрипты. В итоге единственный способ превратить Make в более-менее понятную для человека инкрементальную систему сборки можно видеть на примере Андроида — фактически изобрести новый ЯП поверх Make.

Ninja изначально позиционирует себя, по словам автора, в роли узкоспециализированного ассемблера системы сборки, код которого должен генерировать язык более высокого уровня, такой как CMake.

http://martine.github.io/ninja/

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

узкоспециализированного ассемблера системы сборки, код которого

должен генерировать язык более высокого уровня, такой как CMake

На тяжелые вещества больше смахивает. Мало того, что глючный cmake криво генерит мейкфайлы, и как что-то пошло не так, то концы не найти. А здесь еще один уровень генерации, вероятно для повышения уровня занимательности времяпрепровождения при отладке.

Cmake - это NIH же, «мы не осилили autotools, но зделаем систему лудше». Ни один приличный кроссплатформенный проект на такое не купится. Вот например OpenJDK, над ним последние пару лет работа кипит, почти полтысячи человек им занимаются сейчас. В прошлом году полностью переписали всю сборку проекта. До этого были простые мейкфайлы. А заменили их разумеется не на scons/cmake/прочую_ересь, а на autotools (которого раньше там не было). Потому что, когда надо чтобы сборка надежно работала - есть проверенные средства. А для желающих себе ноги отстреливать - да, выбор систем сборки широкий.

anonymous
()
Ответ на: комментарий от anonymous

Вы тут про вещества упомянули, но, поправьте если ошибаюсь, тот же autotools работает по аналогичной схеме, через генерацию Makefile.

Dendy ★★★★★
()

Чудесно. Надеюсь, Патрик одобрит до релиза 14.1

GreenTea ★★
()
Ответ на: комментарий от anonymous

Что интересно, я ни разу не видел в промышленном кроссплатформенном проприетарном коде использования autotools, везде почему-то используется «scons/cmake/прочая_ересь».

Reset ★★★★★
()
Ответ на: комментарий от Dendy

Ога, автотулз генерит мейкфайлы. Много лет это делает. Все возможные кривости хорошо известны. Он как maven в java - сложный, громоздкий, неидеальный, но при этом решает очень сложную проблему и делает это хорошо. Если надо что-то проще сделать, то трезвые люди выбирают подход проще. В гугле например, андроид SDK кастомные ant скрипты использует (здесь ant - это аналог make), а android NDK - убер-makefile с кучей готовых тасков, которому надо только параметры проекта скормить. И заметьте, никакой генерации.
Если нужны автотулз-лайк возможности - надо использовать автотулз. Если сборку можно проще построить - надо что-то более простое. А переписать автотулз но по своему, это либо много свободного времени + вещества, либо, как в приведенных выше проприетарных проектах, банальный job safety (привязка рабочего места к себе в смысле). Здесь чем больше ереси и уровней кодогенерации - тем лучше, пока на тебя завязана сборка флагманского продукта компании, можно не работать и продолжать получать зарплату.

anonymous
()
Ответ на: комментарий от anonymous

А заменили их разумеется не на scons/cmake/прочую_ересь, а на autotools (которого раньше там не было).

А почему, знаешь?

crowbar
()
Ответ на: комментарий от crowbar

Нет, не знаю. Судя по твоим вопросам, здесь есть какая-то скрытая причина помимо чистой и быстрой кроссплатформенной сборки?

anonymous
()
Ответ на: комментарий от NaN

python??? дурак чтоле? ещё этого говна в make нехватало.

anonymous
()
Ответ на: комментарий от Dendy

Одна беда, написано на плюсах, говно-синтаксис и всё такое. Никто не будет разбираться в сорцах и развивать проект, если аффтар на него забъёт, ибо проще всё с нуля переписать на нормальном языке. Я бы не делал бы ставку на данное решение.

anonymous
()
Ответ на: комментарий от anonymous

Поддерживаю! К сожалению cmake не решает заявленных задач. А пляски с бубном в случае если что-то пошло не так гарантированы. Ну просто хрен поймёшь что ему не нравится. Ошибки не информативны — не хватает зависимости, а ругается совсем на другое, и подобная хрень сплошь и рядом.

К моему великому сожалению, на текущий момент autotools заменить нечем.

anonymous
()
Ответ на: комментарий от Reset

Что интересно, качество кроссплатформенного проприетарного кода оставляет желать лучшего (глаза б мои его не видели). А тащат scons/cmake туда вендузятники, что бы сборка под линукс в вижуалстудии работала.

Выводы делай сам.

anonymous
()
Ответ на: комментарий от Dendy

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

Это пишет человек, превозносящий cmake... Более ущербного и дикого синтаксиса, чем у cmake, я не видел. make по сравнению с cmake — конфетка.

anonymous
()
Ответ на: комментарий от anonymous

Более ущербного и дикого синтаксиса, чем у cmake, я не видел. make по сравнению с cmake — конфетка.

Согласен, язык жуткий, зачем его изобрели для меня загадка. Для системы сборки идеально подошёл бы тот же Python с его динамической типизацией, исключениями, богатой библиотекой модулей и конструкциями языка, сильно упрощающими жизнь. В CMake даже два числа сложить или строку разобрать уже проблема. А написать функцию стаёт уделом джедаев.

Но Make тоже перехвалить сложно, возможности языка очень слабые и давно себя изжили,сейчас они явно не решают поставленных задач. Конструкции для пересборки целей спорны, отсутствует история выполнения команд, с которыми была собрана цель, ориентирование исключительно на время последнего изменения файла — этого явно недостаточно для инкрементальной сборки. Чтобы написать функцию на Make нужно сначала защитить диссертацию по написанию функций в Make, простые смертные даже заглядывать в исходный код не должны для сохранения ясности рассудка.

Сейчас учавствую в проекте, в котором система сборки на Make с завидным упорством переписывается уже в который раз. Чем посмотреть на рынок систем сборки этим людям наверное доставляет удовольствие изобретать велосипед и прыгать по граблям. В итоге последняя реинкарнация уже не содержит создание целей прямо в файле проекта, вместо неё инициализация предустановленных переменных с последующим include куска Makefile, который их понимает.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

Чтобы написать функцию на Make нужно сначала защитить диссертацию по написанию функций в Make, простые смертные даже заглядывать в исходный код не должны для сохранения ясности рассудка.

Ничего подобного, там все элементарно. Главное не стесняться использовать рекурсию :3

vasily_pupkin ★★★★★
() автор топика
Ответ на: комментарий от Dendy

Я вот, кстати, периодически занимаюсь тем, что написано в последнем абзаце. Сложно сказать, как то этого дошло. Рынок систем сборки забит разным говнищем, которое все равно приходится допиливать. gmake простой как угол дома, переносимый, рецепты для него напиливать проще.

Скорее всего на каком-то этапе перейду на IEEE sh + ninja

vasily_pupkin ★★★★★
() автор топика
Ответ на: комментарий от Dendy

Для системы сборки идеально подошёл бы тот же Python с его динамической типизацией, исключениями, богатой библиотекой модулей и конструкциями языка, сильно упрощающими жизнь.

Python - язык общего назначения. А система сборки должна быть ограниченной и декларативной, чтобы можно было генерить код проектов любой возможной IDE. Ничего «вычислимого» в системе сборки не должно быть вовсе.

В CMake даже два числа сложить или строку разобрать уже проблема.

Руки отрывать за такое.

anonymous
()
Ответ на: комментарий от vasily_pupkin

Вот открыл наугад из Андроида:

define find-parent-file
$(strip \
  $(eval _fpf := $(wildcard $(foreach f, $(2), $(strip $(1))/$(f)))) \
  $(if $(_fpf),$(_fpf), \
       $(if $(filter-out ./ .,$(1)), \
             $(call find-parent-file,$(patsubst %/,%,$(dir $(1))),$(2)) \
        ) \
   ) \
)
endef

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

Dendy ★★★★★
()
Ответ на: комментарий от anonymous

А вот и школоло понабежало.

Расскажи, тупое школоло, почему в LLVM переходят на CMake с autotools?

anonymous
()
Ответ на: комментарий от anonymous

А система сборки должна быть ограниченной и декларативной

На счёт декларативности можно поспорить, к примеру тот же CMake полностью императивный, что не мешает ему выполнять свои задачи. Но я с интересом наблюдаю и за идеей QBS, в основе которого QML как декларативный язык с возможностью императивщины на JS.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

Android NDK - куча говна. Они слишком злоупотребляют eval'ом и портят стандартный механизм наполнения переменных. Скорее всего чуваки которые её напиливали, видели gmake в первый раз.

Для своих костылепроектов я перешел на собственный вариант билда под андроид, используя тулчейны NDK напрямую.

Конкретно эта функция рекрурсивно отпиливает куски пути и проверяет наличие файлов в получившемся каталоге вайлдкардом. Мне кажется, вполне прозрачно написано, хотя лучше бы в пару разложить :D

vasily_pupkin ★★★★★
() автор топика
Ответ на: комментарий от anonymous

каких интересно задачь не решает cmake? звучит так что вы просто не понимаете о чем говорите. давно уже пользуюсь cmake и он прекрасен. кросс-сборки, сборка под VC (под mingw сложные проекты собирать моветон - половина новых API не доступна, тот-же Google Chrome собирается через VC компиляторы), поддержка кучи тулзов «из каропки» (Qt, Doxygen и так далее), драйвер юнит тестов (умеет даже их паралелить аля ctest -j5), пекейджер (разные zip'ы и прочие инсталяторы генерить с минимум усилий). ничего этого нет в autotools. плюс autotools + make безбожно тормозят по сравнению c cmake + ninja (на винде в тройне безбожно тормозят, вот только в gmake 4.0 наконец сделали сервер паралелизации, раньше его тупо небыло, т.е. -j3 не работал, только неограниченный -j). кросс-сборка или канадский-крест с autotools кстати говоря еще тот цирк, _постоянно_ вылезают проблемы, без патчей и хаков даже не лезь, а configure.ac для поддержки таких компиляций монстрятина еще та (видимо поэтому и ломаются постоянно в gcc). в cmake кросс-компиляция не идеальна но не настолько ущербна как в auto-tools имхо, она тупо надежней и проще за счет import/export таргетов между стейджами.

anonymous
()
Ответ на: комментарий от anonymous

под mingw сложные проекты собирать моветон

Немного оффтопом, есть соображения, отчего так сложилось? MSVC использовать в кроссплатформенной сборке - это очень больно (астрологи объявили месяц cygwin'а, количество проблем и время сборки выросли по экспоненте). MinGW64 же требует минимального допиливания сборки (если код винду поддерживает). С99 опять же там есть. Скорость бинарников из MinGW сранима с MSVC и даже выше. При этом все большие проекты под винду (python, postgres и т.д.) используют MSVC. MinGW недостаточно стабильный вероятно? Я в нем никогда с проблемами не сталкивался, но и ничего серьезного не собирал на нем.

anonymous
()
Ответ на: комментарий от Dendy

Да, возможно за этим будущее. Однако в огромном множестве проектов используется Make, по крайней мере как бэкэнд. И чтобы заменить его уйдёт уйма времени. Вот ещё одна попытка сделать Make правильным http://gittup.org/tup/make_vs_tup.html

Taliriktug
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.