LINUX.ORG.RU

GNU make 3.82

 ,


0

0

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

Обновление носит значимый характер и включает некоторые несовместимые с предыдущими версиями изменения.

  • анонсировано удаление функций сортировки по маске, рекомендуется пользоваться $(sort ...)
  • ввиду изменения в 2008 году стандарта POSIX , теперь требуется вызывать шелл с ключом -e , подобное может быть несовместимо с многими имеющимися makefile's и пока потребует указания переменных .POSIX или .SHELLFLAGS
  • переменная $? теперь содержит все предзависимости (даже те которых пока не существует), ранее переменная содержала только существующие цели.
  • расширены директивы парсера, анонсированы три возможные несовместимости: 1) предзависимость содержащая = больше не может заканчиваться обратным слешем, нужно создавать переменную с = и использовать ее в правилах для цели. 2) в именах переменных более недопустимы пробелы. 3) прямые цели (explicit target) и цели по шаблону (pattern target) теперь не могут сосуществовать в одном правиле сборки
  • правила для переменных и правил шаблонов теперь будут применяться по наиболее короткому пути, а не в порядке их определения. Определяется ключем shortest-stem в переменной .FEATURES
  • поиск библиотек теперь производиться также как его делает компоновщик (ранее для -lfoo просматривались libfoo.so в текущем каталоге, путях vpath и системных каталогах, потом производился поиск статической библиотеки по этим же путям, теперь один и тот же путь будет проверяться сначала на libfoo.so, а потом на libfoo.a)

из других изменений:

  • новый ключ командной строки --eval=STRING, идентичен директиве $(eval ...), будет обработан после определения правил и переменных по умолчанию, но перед обработкой любых makefile
  • новая специальная переменная .RECIPEPREFIX позволяет переопределить начало рецепта (recipe introduction) с табуляции (tab) на что-то другое
  • новая специальная переменная .SHELLFLAGS позволяет управлять вызовами шелла, по умолчанию это будет ключ -с или -ec, если установлена переменная .POSIX
  • новая специальная цель .ONESHELL укажет make вызвать шелл и вызвать команду сборки всего рецепта (recipe) вне зависимости от числа строк в нем. Для совместимости с POSIX шеллами контрольные символы «@», «+» и "-" будут отфильтрованы.
  • модификатор переменных private запретит наследование этой переменной в предзависимостях
  • директива undefine (для удаления переменной)
  • обработчик теперь будет воспринимать множественные модификаторы export, override, private на одной строке и в любом порядке, также можно создавать цели и переменные с такими именами
  • директива define теперь разрешает использовать оператор назначения переменной, что особенно облегчает работу с многострочными переменными
  • Исправлены многочисленные ошибки

>>> анонс на savannah.gnu.org

★★★★★

Проверено: svu ()
Последнее исправление: hibou (всего исправлений: 2)
Ответ на: комментарий от Odin

> тебе на это понадобилось 8 лет? ;)

Не трогайте человека, у него горе. Портирует Gentoo на Z-80...

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

Scons — унылая и кривая поделка. На том же питоне есть более православный waf. Ну, а вообще, cmake же есть) Но обычный make тоже нужен (хотя бы для того же cmake'а).

buddhist ★★★★★
()

> поиск библиотек теперь производиться также как его делает компоновщик

поиск производиться

также как


brutal facepalm

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

Но обычный make тоже нужен (хотя бы для того же cmake'а).

ага, обычный, а не gmake, а вот для configure нужен только gmake

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

> Без configure неудобно задавать 100+1 параметр сборки.

С CMake это делается намного проще. Кроме того есть фронтенды ccmake и всякие гуйные, в которых это еще проще.

Deleted
()
Ответ на: ant от BillDver

ant на жабе. Не катит.

Deleted
()
Ответ на: ant от BillDver

Ant примитивен и ориентирован на Жабу. На любой нестандартный чих там необходимо писать плагин. Make, между тем, легок и понятен, а в GNU Make много вкусностей. Единственная нормальная альтернатива make'у - Jam, но он глючноват и философски недоработан.

faustus
()

а дерево зависимостей оно строить так и не научилось?

чтобы сказать

make -ключик таргет

и оно выдало

таргет: список всего от чего зависит

в сложных проектах когда имеем множество директорий с собственными make было бы здорово зависимости строить такой фичей

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

GNU make 3.80 Released
posted by psmith, Чтв 21 Ноя 2002 01:26:23 - 0 ответов
да, я от 3.80 посчитала. спс

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

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

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

соответствнно задача: если изменились медиаданные или изменились файлы исходники - пересобрать пакет. иначе не пересобирать.

получается что в «верхнего уровня» make надо _всегда_ запускать оба дочерних make, поскольку дерево зависимостей «дочек» он не знает.

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

>С CMake это делается намного проще. Кроме того есть фронтенды ccmake и всякие гуйные, в которых это еще проще.

Мы наверно на разных планетах живём, и понятия простоты у нас разные, если после прочтения sabz --help получаются настолько разные выводы. ccmake конечно хорош, для разового применения. Но иногда нужно повторять один и тот же результат несколько раз в течении длительного времени. На память надеяться глупо, лучше загрузить в неё что-то более полезное. То есть придётся поштучно копипастить все вносимые в гуй изменения в шпаргалку и скриншоты а потом поштучно воспроизводить в обратном порядке. В случае с configure достаточно скопипастить всего одну команду. Гуёвый кошмар «кнопочку потерял, потратил на поиски несколько часов» не миф а реальность:) Однажды, в оффтопике, процесс поиска кнопки занял полгода, пока однажды кто-то не наткнулся и не подсказал.

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

Как по мне это не очень удобно.

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

Я делаю так. В корневом CMakeLists.txt пишем

if (EXISTS "${CMAKE_BINARY_DIR}/settings.cmake")
include(${CMAKE_BINARY_DIR}/settings.cmake)
endif()

Соответственно если в директории сборке есть файл settings.cmake, то он подключается и используется. В проект можно включить примеры типичных settings.cmake для типичных платформ и типов сборок. Тогда вообще никогда ничего писать и читать не придется, а достаточно будет скопировать settings.cmake из примеров в директорию сборки.

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

Как и следовало ожидать, облегчение написания программ влечёт некоторое усложнение использования на первоначальном этапе)

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

>дерьмо мутное этот ваш скунс - стоит немного отойти от заложенных внутри шаблонов - и сборка превращается в бубновую пляску. make рулит.

Может, стоить немного разобраться и научиться пользоваться? Или примеры плясок на бочку.

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

>Scons — унылая и кривая поделка. На том же питоне есть более православный waf. Ну, а вообще, cmake же есть)

1. Безусловно, scons нуждается в дальнейшем совершенствовании. А кто нет? 2. waf хорошее развитие, но далеко не все решения можно признать удачными. Скорее, эта ветка провалилась, чем нет. Единственный плюс — повышенная скорость работы. 3. cmake нуждается в двойном перезапуске на каждый чих, при том что скорость генерации мэйкфайла не самая космическая. В этом смысле, сконс безусловно на порядки удобнее.

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

>вот имеем проект состоящий из двух подпроектов. например первый make собирает медиаданные для игрушки, второй собирает собственно игрушку а внешний над ними мейк собирает всю игрушку в общий пакет.

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

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

>Почему в этом топике прозвучало scons но не прозвучало cmake? который является великолепной кросс-платформенной метасистемой сборки, попробуйте своим сконсом сгенерируйте проекты для Visual Studio

«патамушта» внимательнее читаем документацию и с удивлением понимаем, что scons: 1) не требует перезапуска на каждый чих — стандартное действие при активной разрабоке, угу? 2) не менее, если не более кроссплатформенный, угу?

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

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

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

>> Вот генерировать файлы для сторонних систем сборки, а-ля встроенные сборочницы эклипса или той же студии, да, не обучен

оно и не надо
под гцц бы хоть собрать

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

1. Можно, при желании, конфигурировать так же, как CMake, тогда тоже одну комманду достаточно скопировать.
2. Есть файл (насколько я помню, называется CMakeCache.txt), который достаточно скопировать и все будет.

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

> под гцц бы хоть собрать

в чём проблема? может, подскажу.

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

Вот генерировать файлы для сторонних систем сборки, а-ля встроенные сборочницы эклипса или той же студии, да, не обучен. Вы не находите, что это совсем не требуется?

не нахожу

Не его это задача.

а чья? неужели человека? тогда придется поддерживать два файла проекта, а это двойной геморрой

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

>не нахожу

Напрасно.

Не его это задача.

а чья? неужели человека?

Кто-то мешает собирать проект тем же сконсом на всех платформах? Собственно, он для этого и разработан. Кстати, сконс (обычно) ещё и гибче, чем встроенная собиралка.

Зы: с visual studio scons таки бесшовно интегрируется.

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

Кто-то мешает собирать проект тем же сконсом на всех платформах? Собственно, он для этого и разработан. Кстати, сконс (обычно) ещё и гибче, чем встроенная собиралка.

А вести разработку как? Я хочу открыть sln и увидеть все свои файлы и цели. Хочу нажать F5 и запустить отладку. При этом я не хочу vcproj'ы редактировать руками.

Reset ★★★★★
()

Боже, дай этой поделке скорой и мучительной смерти.

Каждый релиз ломают обратную совместимость. Это что, такой вид садизма?

Выкачал софт, что собирается GNU make, и дальше пол дня трахаешься, пытаясть его собрать под разными версиями этого отстоя.

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

> они сделают для отдельный бэкэнд для GNU make день сломавшегося парсера на ЛОРе?

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

>А вести разработку как? Я хочу открыть sln и увидеть все свои файлы и цели. Хочу нажать F5 и запустить отладку. При этом я не хочу vcproj'ы редактировать руками.

use CMake, Luke

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

>А вести разработку как?

Как обычно?

Я хочу открыть sln и увидеть все свои файлы и цели

я не знаю, существует ли плагин для студии, позволяющий визуализировать «все файлы и цели». Может, и существует.

Только фишка-то в том, что вы и так их прекрасно видите. src/подпроект/модуль/Sconcript и пишите цель в самом общем виде на здоровье. С неявными зависимостями сконс разберётся сам.

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

Как обычно?

Это руками делать проект для студии? Нафиг нафиг.

Только фишка-то в том, что вы и так их прекрасно видите. src/подпроект/модуль/Sconcript и пишите цель в самом общем виде на здоровье. С неявными зависимостями сконс разберётся сам

Еще раз повторяю, что я не хочу ничего делать руками, хочу чтоб всё было само по нажатию кнопки F5 в студии. CMake такую возможность мне дает.

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

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

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

> Как обычно?

Это руками делать проект для студии? Нафиг нафиг.

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

Еще раз повторяю, что я не хочу ничего делать руками, хочу чтоб всё было само по нажатию кнопки F5 в студии. CMake такую возможность мне дает.

Так уж ничего не делаете «руками»? Ну, вот у меня, скажем, в src/units/modules/moduleOPUS лежит код на сях и фортране. Часть сишного кода собирается с одними ключами, часть другими, часть образует библиотеку (ну, так захотел оригинальный автор), часть исполняемый бинарник. И там и там задействованы группы одних и тех же исходников. Каким образом указать это безобразие, «ничего не делая руками»?

В случае сконса, всё элеметарно: подсовываем целям разные окружения, сформированные для этих случаев (env.SharedLibrary(бла-бла...), env2.Program(бла-бла...) и готово. Как это делать «не делая руками»?

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

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

>я смотрел в свое время сконс, тогда он мне показался жутко неудобным,

В него надо въехать. Некоторые базовые принципы (которые все используют!) практически не описаны в документации, хотя отражены в факах.

опять же пейтон вместо специально созданного декларативного языка ...

Опс. Опять изобретаем велосипед? Ну окей, придумайте алгоритмически полный декларативный язык, давайте. Ну я спрошу — а нафига? Чем не устраивает тот же питон?

ЗЫ: если для какого-то проекта мне понравятся хитрозадые проверки, я даже не буду задумываться, как их реализовать в случае сконса: питон и все дела. А как в случае «специального декларативного языка»? Например, тривиальный и очень простой пример. Проект собирается для линукса и виндоуса, причём не с помощью кросскомпиляции, а так было нужно — с двух реальных машин, папка проекта на самбе. Пришлось ещё для макоси (аналогичным образом). В сконсовых проектах — три строчки проверки, и проект собирается в #build/posix/module1...moduleN, #exe/posix и #exe/MacosX, #exe/Windows соотв.Прошу пример, как это следует делать Вашими любимыми средствами.

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

>сконс не генерит мейкфайлы, что неудобно

бред какой-то. Сконс делался для того, чтобы забыть о мэйк файлах раз и навсегда.

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

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

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

>Часть сишного кода собирается с одними ключами, часть другими, часть образует библиотеку (ну, так захотел оригинальный автор), часть исполняемый бинарник. И там и там задействованы группы одних и тех же исходников. Каким образом указать это безобразие, «ничего не делая руками»?

я бы сказал, что это не только в CMake, но и в GNU make сделать не так сложно

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