После полутора лет разработки представлен (http://lists.gnu.org/archive/html/info-gnu/2016-05/msg00013....) релиз системы сборки GNU Make 4.2 (http://www.gnu.org/software/make/). Кроме исправления ошибок, в новой версии можно отметить следующие улучшения:- Добавлена новая переменная $(.SHELLSTATUS), в которой передаётся статус возврата последней функции "!= " или $(shell ...), вызванной из текущего экземпляра make. Ноль означает успешное выполнение, а иное другое значение - не успешное;
- Функция $(file ...) теперь может читать из файла и при указании $(file ‹FILE) распространяется на содержимое файла;
- Показываемые номера строк make-файлов теперь явно определяют строку, с которой связана проблема или предупреждение.
- Стабилизирован и документирован интерфейс "jobserver (http://tech-digby280.blogspot.com/2012/03/gnu-make-job-serve...)". Нарушена обратная совместимость: внутренняя опция командной строки "--jobserver-fds" в итоговой спецификации опубликована как "--jobserver-auth";
- Уровень распараллеливания сборки может быть определён через MAKEFLAGS, даже при включенном jobserver (ранее MAKEFLAGS не принимался во внимание при включении jobserver).URL: http://lists.gnu.org/archive/html/info-gnu/2016-05/msg00013....
Новость: http://www.opennet.ru/opennews/art.shtml?num=44475
Годно!
Юный падаван имел в виду вот это?> Показываемые номера строк make-файлов теперь явно определяют строку, с которой связана проблема или предупреждение.
очевидно, юный падаван имел ввиду саму утилиту.
а номер строки make-файла - штука специфичная - у тов.Анонима, который я, за 13 лет разработки под никсы ни разу такой потребности не возникало.
> я, за 13 лет разработки под никсы ни разу такой потребности не возникало.Получается ребята напрасно старались раз тебе это не нужно?
> Получается ребята напрасно старались раз тебе это не нужно?Нет, получается, что сама make нужна бОльшему числу людей, чем отображение номеров строк.
Юный падаван имел в виду развие проекта в целом.
Пока для себя лучшей сисемы сборки не вижу, да и всё равно стандарт в никсах де-факто.
> Юный падаван имел в виду развие проекта в целом.
> Пока для себя лучшей сисемы сборки не вижу, да и всё равно
> стандарт в никсах де-факто.Ну вот теперь всё ясно и понятно, неужели было трудно с самого начала так же чётко сформулировать свою радостную эмоцию и не интриговать посетителей попусту.
Что такое подаван ?
Чем юный п. отличается от пожилого п. ?
> Что такое подаван ?Правописание хромает. Надо писать "подован". Проверочное слово: "корован".
В каком веке будет корректная обработка правил с генерацией нескольких файлов?
Тов Анонимус любит Fortran ??
> Тов Анонимус любит Fortran ??А что это запрещено? Даже про запреты фортран-парадов и пропаганды фортрана посреди подрастающего поколения ничего не слышно, а уж тем более на опеннетике.
Нет, литературное программирование.И просто глупо поддерживать совместимость с багами сорокалетней давности.
Скорее, Protocol Buffers. Там из одного .proto генерируются одновременно .cc и .h.
ЕМНИП в lex и yacc аналогично.
> В каком веке будет корректная обработка правил с генерацией нескольких файлов?пока не придумали специального синтаксиса для задания правил с генерацией нескольких целей одним правилом, но можно использовать уже имеющиеся возможности, например так (на примере работающего Makefile):
#######
# объявляем переменную-отсечку: если её значение переменной не пустое, значит правило генерации выполнено и ещё раз вызывать его не надо
check:=
# объявляем order-only зависимости между сгенерёнными файлами
# это нужно для того, чтобы задержать выполнение правил трансляции b1.c->b1.o и c1.c->c1.o до тех пор, пока не будет выполнена ре-генерация файлов a1.c, b1.c, c1.c из x.x (одним вызовом правила генерации нескольких целей) (при повторном вызове make после изменении x.x)b1.c: | a1.c
c1.c: | b1.c# правило генерации нескольких целей
# сгенерим a1.c, b1.c, c1.c из x.x одним вызовом touch a1.c b1.c c1.c
# установим переменную-отсечку, чтобы вызвать правило генерации только один раз
# не выполняем правило, если переменная-отсечка установленаa1.c b1.c c1.c: x.x
$(if $(check),,$(eval check:=1)touch a1.c b1.c c1.c)# правила трансляции a1.c->a1.o, b1.c->b1.o и c1.c->c1.o
c1.o: c1.c
touch $@
b1.o: b1.c
touch $@
a1.o: a1.c
touch $@# основная цель
all: c1.o b1.o a1.oclean:
rm -f a1.c b1.c c1.c a1.o b1.o c1.o.PHONY: all clean
.DEFAULT_GOAL := all
>пока не придумали специального синтаксиса для задания правил с генерацией нескольких целей одним правилом
>a1.c b1.c c1.c: x.xспециальный синтаксис там сейчас сделан
>>пока не придумали специального синтаксиса для задания правил с генерацией нескольких целей одним правилом
>>a1.c b1.c c1.c: x.x
> специальный синтаксис там сейчас сделанПример?
Только без pattern-rules - они очень мешают при нерекурсивной системе сборки.
Использование такой конструкции не для генерации нескольких целей - это и есть специальный синтаксис.
Ну, видимо вопрос был про следующий случай.gen создает _два_ файла, a и b.
c: a b
process a b > c# плохо: если нет ни a ни b,
# gen x вызовется два раза, а при параллельном make
# может быть совсем нехорошоa b: x
gen xСпособа указать "выполнить gen x один раз, если или a или b старше x или не существует" сейчас нет.
>a b: xСейчас это считается двумя независимыми правилами вместо одного. Что курил автор GNU Make?
a b: x
ruleэквивалентно
a: x
ruleb: x
ruleи все вполне логично. Проблема в том, что для неявных правил подразумевается, что одна команда может нагенерить пачку файлов (что и делают копиляторы), а для явных правил это выразить нельзя.
>все вполне логичноfacepalm
Без неявных правил можно выжить, а без явных правил совсем никак. Необходимо сначала сделать полноценные явные правила, а потом уже шлифовать неявные правиа.
Кстати, две похожие проблемы с большинством учебников по виму (говорю как вимер):
1. куча команд типа "удалить от курсора до предпоследнего слова предпоследнего предложения предпоследнего абзаца", и потом полторы строчки типа "поклонники notepad могут выделять любые блоки движением курсора"
2. "забудьте про стрелочки, наша секта должна страдать"
>[оверквотинг удален]
> gen создает _два_ файла, a и b.
> c: a b
> process a b > c
> # плохо: если нет ни a ни b,
> # gen x вызовется два раза, а при параллельном make
> # может быть совсем нехорошо
> a b: x
> gen x
> Способа указать "выполнить gen x один раз, если или a или b
> старше x или не существует" сейчас нет._Красивого_ способа указать нет.
Некрасивый - с использованием переменной-отсечки.
Работает, правда, через eval, но работает же.
И с jobserver'ом - при запуске make -j
Когда уже все перейдут на что-нибудь типа QBS и похоронят эту архаичную хрень?
Когда вы перепишете linux, gcc, binutils и glibc на Qt.
Что стартовало в начале 90-х и раньше - так и использует инструментарий-современник.Что стартует сейчас - по возможности использует что-то современное.
Например GNU Make 4.2
Qt тут не при чем (разве что QBS разрабатывает та же организация что и Qt). Речь идет о том, что make - древний архаизм с кучей недостатков и костылей, почитать о которых можно например https://habrahabr.ru/post/138682
И вряд ли переход должен делать я:) Это задача сообщества в целом, и лидеров в особенности - понять что инструмент родом из 70-х годов объективно устарел, принять принципиальное решение о необходимости перехода, проанализировать альтернативы, выбрать, разработать поэтапный план и начать его выполнять.
Да как вы задолбали юнные революционеры, сделайте хороший инструмент вам спасибо скажут, а не х..ню на перле как вы любите.
> юнные революционеры
> на перлеА не отстал ли ты от жизни?
А не зажрались ли вы по 1Гб памяти тратить на юмы?
> Речь идет о том, что make - древний
> архаизм с кучей недостатков и костылей, почитать о которых можно например
> https://habrahabr.ru/post/138682большинство претензий в статье преувеличено, раздуто, а некоторые не соотвествуют действительности.
> понять что инструмент родом из 70-х годов объективно устарел, принять принципиальное решение о необходимости перехода, проанализировать альтернативы, выбрать, разработать поэтапный план и начать его выполнять.
займитесь. Ведь некоторых, например меня, вполне устраивает архаичный GNU make.
Ну да, круглое колесо - это древний архаизм. Нужно сделать квадратное.
> Ну да, круглое колесо - это древний архаизм. Нужно сделать квадратное.Нет, но уже изобрели паровую машину, которая по рельсам может тянуть груз сотен телег.
Хотя некоторым и привычней по старинке, лошадками (а то и ножками), постоянно трын^W твердя, что раз по этим буеракам шайтан-машина не пройдет, то значит вообще не нужна!А еще куча людей возится с крылом, кто-то собирает дирижоп^W дирижаблю (а особо одаренные с ничего-прыжками и транпурти... транспори... ничего-траспартировкой – тьфу, язык сломишь) хотя все знают, что если бы Главный Архитектор Этой Симуляции хотел, чтобы мы летали, то подарил бы нам крылья вместо колеса!
> то подарил бы нам крылья вместо колеса!Так иному дай крылья -- он их всё равно расшибёт... об осину.
круглое колесо запатентовали
Я был активным сторонником QBS, писал про него на хабре, активно юзал и репортил баги.
Но на сегодняшний день я в нем разочарован и перешел на CMake.Минусы: очень медленная разработка - до сих пор не вмерджили мои патчи по генерации проектов для студии (хотя замечаний, что исправить там нет.)
нет удобного configure для зависимостей (да, запилили пробки, но попробуйте их юзать вместе с Depends)
-слабая поддержка других IDE кроме QtC (отчасти затык в генераторах)
-адски медленные инкрементные билды, если начинаешь хоть сколько-то юзать wildcards - с cmake такой проблемы нет.Единственный его крупный плюс- достаточно легкий лаконичный синтаксис.
> И вряд ли переход должен делать я:) Это задача сообщества в целомА кто Вы, извините, такой, чтоб ставить сообществу задачи?
Мне вот надо -- я себе в уголочке и пилю на gnu make, с другими делюсь.
Огорчаюсь от деятелей, которые понарожали всяких шмяков со скунсами (в котором *даже* я оказался способен найти критичный, притом совсем инфантильный, баг), это да...
и утро начинаем с прекомпиляции всех прог -
что-то я не понял про SHELLSTATUS они хотят сказать что раньше make на проверял статус завершения программ которые он запускает?
> что-то я не понял про SHELLSTATUS они хотят сказать что раньше make
> на проверял статус завершения программ которые он запускает?речь идёт о встроенной, (редко используемой)) функции $(shell) - выполнения команды и записи результата в переменную.
a := $(shell ls)
Да, раньше статус возврата ls в make узнать было нельзя.
$(shell) используется для чтения stdout - если значение $a пустое, значит ls завершился с ошибкой.
> речь идёт о встроенной, (редко используемой))Как это редко используемой?
CFLAGS+=`pkg-config gtk+-2.0 --cflags`
или
CFLAGS+=$(shell pkg-config gtk+-2.0 --cflags)Можно глянуть в vlc: contrib/src/main.mak
По-хорошему pkg-config должен вызывать configure, а не make.
Редко используемой - потому что в Makefile вызывать $(shell) долго и дорого. Потом удивляются, почему сборка тормозит.
Звучит логично. Надо будет обращать внимание.
проверил, к счастью код возврата выполняемой программы проверяется и все тормозиться если какой нибудь gcc вернул не 0
Раз уж в тредике собрались и специалисты, а не только махатели чужой шашкой -- вдруг кому-то пригодится полезная подборка маленьких хитростей по gmake: http://www.cmcrossroads.com/ask-mr-make
Пробелы в именах файлов и директорий когда будут восприниматься в make?
А что, сейчас игнорируются?))
Пробелы в путях к файлам в правилах нужно эскейпить, что, правда, вручную делать жутко не удобно.
Хорошо, что редко когда это нужно - всегда можно проект расположить в директории без пробелов в путях (на виндах можно сделать отображение директории на диск через subst), а пути к системным хедерам, пожалуй, встречаются только в опциях компилятора и автогенеренных dep-файлах зависимостей.
Если посмотреть на другие системы сборки, на то, как в них сделана обработка строк - например в cook от https://en.m.wikipedia.org/wiki/Peter_Miller_(software_engineer) - то в Gnu make сценарии сборки получаются "чище", легче читаются, чем в cook, именно из-за отсутствия необходимости эскейпить кавычки где-нибудь в регулярном выражении для вызываемого sed.
> Если посмотреть на другие системы сборки, на то, как в них сделана обработка строк - например в cook от https://en.m.wikipedia.org/wiki/Peter_Miller_(software_engineer) - то в Gnu make сценарии сборки получаются "чище", легче читаются, чем в cook, именно из-за отсутствия необходимости эскейпить кавычки где-нибудь в регулярном выражении для вызываемого sed.Зато регулярные выражения с $ внутри make --- $$$$ ;)