| |
| 2.3, Анончег (?), 22:18, 22/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Юный падаван имел в виду вот это?
> Показываемые номера строк make-файлов теперь явно определяют строку, с которой связана проблема или предупреждение. | | |
| |
| 3.4, Аноним (-), 22:30, 22/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
очевидно, юный падаван имел ввиду саму утилиту.
а номер строки make-файла - штука специфичная - у тов.Анонима, который я, за 13 лет разработки под никсы ни разу такой потребности не возникало.
| | |
| |
| 4.5, Анончег (?), 22:52, 22/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> я, за 13 лет разработки под никсы ни разу такой потребности не возникало.
Получается ребята напрасно старались раз тебе это не нужно?
| | |
| |
| 5.12, Аноним (-), 23:42, 22/05/2016 [^] [^^] [^^^] [ответить]
| +6 +/– | |
> Получается ребята напрасно старались раз тебе это не нужно?
Нет, получается, что сама make нужна бОльшему числу людей, чем отображение номеров строк.
| | |
|
|
| 3.9, kachsheev (ok), 23:38, 22/05/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Юный падаван имел в виду развие проекта в целом.
Пока для себя лучшей сисемы сборки не вижу, да и всё равно стандарт в никсах де-факто.
| | |
| |
| 4.14, Анончег (?), 00:13, 23/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Юный падаван имел в виду развие проекта в целом.
> Пока для себя лучшей сисемы сборки не вижу, да и всё равно
> стандарт в никсах де-факто.
Ну вот теперь всё ясно и понятно, неужели было трудно с самого начала так же чётко сформулировать свою радостную эмоцию и не интриговать посетителей попусту.
| | |
| |
| 5.44, e (??), 09:19, 24/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Что такое подаван ?
Чем юный п. отличается от пожилого п. ?
| | |
|
|
|
|
| 1.2, Аноним (-), 21:08, 22/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
В каком веке будет корректная обработка правил с генерацией нескольких файлов?
| | |
| |
| |
| 3.7, Анончег (?), 22:58, 22/05/2016 [^] [^^] [^^^] [ответить]
| +9 +/– | |
> Тов Анонимус любит Fortran ??
А что это запрещено? Даже про запреты фортран-парадов и пропаганды фортрана посреди подрастающего поколения ничего не слышно, а уж тем более на опеннетике.
| | |
| 3.10, Аноним (-), 23:39, 22/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Нет, литературное программирование.
И просто глупо поддерживать совместимость с багами сорокалетней давности.
| | |
| 3.22, kravich (ok), 06:23, 23/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Скорее, Protocol Buffers. Там из одного .proto генерируются одновременно .cc и .h.
| | |
|
| 2.15, anon2 (?), 00:21, 23/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> В каком веке будет корректная обработка правил с генерацией нескольких файлов?
пока не придумали специального синтаксиса для задания правил с генерацией нескольких целей одним правилом, но можно использовать уже имеющиеся возможности, например так (на примере работающего 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.o
clean:
rm -f a1.c b1.c c1.c a1.o b1.o c1.o
.PHONY: all clean
.DEFAULT_GOAL := all
| | |
| |
| 3.17, gvswf556fy24 (?), 00:37, 23/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
>пока не придумали специального синтаксиса для задания правил с генерацией нескольких целей одним правилом
>a1.c b1.c c1.c: x.x
специальный синтаксис там сейчас сделан
| | |
| |
| 4.23, анон2 (?), 10:21, 23/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
>>пока не придумали специального синтаксиса для задания правил с генерацией нескольких целей одним правилом
>>a1.c b1.c c1.c: x.x
> специальный синтаксис там сейчас сделан
Пример?
Только без pattern-rules - они очень мешают при нерекурсивной системе сборки.
| | |
| |
| |
| 6.27, yaa (?), 13:02, 23/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Ну, видимо вопрос был про следующий случай.
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 или не существует" сейчас нет.
| | |
| |
| 7.29, iinmlukkgyjvvv (?), 13:16, 23/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>a b: x
Сейчас это считается двумя независимыми правилами вместо одного. Что курил автор GNU Make?
| | |
| |
| 8.37, yaa (?), 15:27, 23/05/2016 [^] [^^] [^^^] [ответить] | +/– | a b x rule эквивалентно a x rule b x rule и все вполне логично Проблем... текст свёрнут, показать | | |
|
| 7.38, анон2 (?), 17:44, 23/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> 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
| | |
|
|
|
|
|
|
| 1.8, nc (ok), 22:59, 22/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Когда уже все перейдут на что-нибудь типа QBS и похоронят эту архаичную хрень?
| | |
| |
| |
| 3.19, Вареник (?), 00:41, 23/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Что стартовало в начале 90-х и раньше - так и использует инструментарий-современник.
Что стартует сейчас - по возможности использует что-то современное.
| | |
|
|
| 1.13, nc (ok), 23:59, 22/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
Qt тут не при чем (разве что QBS разрабатывает та же организация что и Qt). Речь идет о том, что make - древний архаизм с кучей недостатков и костылей, почитать о которых можно например https://habrahabr.ru/post/138682
И вряд ли переход должен делать я:) Это задача сообщества в целом, и лидеров в особенности - понять что инструмент родом из 70-х годов объективно устарел, принять принципиальное решение о необходимости перехода, проанализировать альтернативы, выбрать, разработать поэтапный план и начать его выполнять.
| | |
| |
| 2.16, cmp (ok), 00:25, 23/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Да как вы задолбали юнные революционеры, сделайте хороший инструмент вам спасибо скажут, а не х..ню на перле как вы любите.
| | |
| |
| 3.21, angra (ok), 05:46, 23/05/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > юнные революционеры
> на перле
А не отстал ли ты от жизни?
| | |
|
| 2.20, anon2 (?), 00:55, 23/05/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
> Речь идет о том, что make - древний
> архаизм с кучей недостатков и костылей, почитать о которых можно например
> https://habrahabr.ru/post/138682
большинство претензий в статье преувеличено, раздуто, а некоторые не соотвествуют действительности.
> понять что инструмент родом из 70-х годов объективно устарел, принять принципиальное решение о необходимости перехода, проанализировать альтернативы, выбрать, разработать поэтапный план и начать его выполнять.
займитесь. Ведь некоторых, например меня, вполне устраивает архаичный GNU make.
| | |
| 2.28, dq0s4y71 (??), 13:16, 23/05/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
Ну да, круглое колесо - это древний архаизм. Нужно сделать квадратное.
| | |
| |
| 3.32, Аноним (-), 13:45, 23/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну да, круглое колесо - это древний архаизм. Нужно сделать квадратное.
Нет, но уже изобрели паровую машину, которая по рельсам может тянуть груз сотен телег.
Хотя некоторым и привычней по старинке, лошадками (а то и ножками), постоянно трын^W твердя, что раз по этим буеракам шайтан-машина не пройдет, то значит вообще не нужна!
А еще куча людей возится с крылом, кто-то собирает дирижоп^W дирижаблю (а особо одаренные с ничего-прыжками и транпурти... транспори... ничего-траспартировкой – тьфу, язык сломишь) хотя все знают, что если бы Главный Архитектор Этой Симуляции хотел, чтобы мы летали, то подарил бы нам крылья вместо колеса!
| | |
| |
| 4.34, Michael Shigorin (ok), 14:55, 23/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > то подарил бы нам крылья вместо колеса!
Так иному дай крылья -- он их всё равно расшибёт... об осину.
| | |
|
|
| 2.31, Владимир (??), 13:28, 23/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Я был активным сторонником QBS, писал про него на хабре, активно юзал и репортил баги.
Но на сегодняшний день я в нем разочарован и перешел на CMake.
Минусы: очень медленная разработка - до сих пор не вмерджили мои патчи по генерации проектов для студии (хотя замечаний, что исправить там нет.)
нет удобного configure для зависимостей (да, запилили пробки, но попробуйте их юзать вместе с Depends)
-слабая поддержка других IDE кроме QtC (отчасти затык в генераторах)
-адски медленные инкрементные билды, если начинаешь хоть сколько-то юзать wildcards - с cmake такой проблемы нет.
Единственный его крупный плюс- достаточно легкий лаконичный синтаксис.
| | |
| 2.33, Michael Shigorin (ok), 14:53, 23/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> И вряд ли переход должен делать я:) Это задача сообщества в целом
А кто Вы, извините, такой, чтоб ставить сообществу задачи?
Мне вот надо -- я себе в уголочке и пилю на gnu make, с другими делюсь.
Огорчаюсь от деятелей, которые понарожали всяких шмяков со скунсами (в котором *даже* я оказался способен найти критичный, притом совсем инфантильный, баг), это да...
| | |
|
| 1.35, Аноним (-), 15:06, 23/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
что-то я не понял про SHELLSTATUS они хотят сказать что раньше make на проверял статус завершения программ которые он запускает?
| | |
| |
| 2.39, анон2 (?), 18:03, 23/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> что-то я не понял про SHELLSTATUS они хотят сказать что раньше make
> на проверял статус завершения программ которые он запускает?
речь идёт о встроенной, (редко используемой)) функции $(shell) - выполнения команды и записи результата в переменную.
a := $(shell ls)
Да, раньше статус возврата ls в make узнать было нельзя.
$(shell) используется для чтения stdout - если значение $a пустое, значит ls завершился с ошибкой.
| | |
| |
| 3.43, Андрей (??), 00:26, 24/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> речь идёт о встроенной, (редко используемой))
Как это редко используемой?
CFLAGS+='pkg-config gtk+-2.0 --cflags'
или
CFLAGS+=$(shell pkg-config gtk+-2.0 --cflags)
Можно глянуть в vlc: contrib/src/main.mak
| | |
| |
| 4.45, анон2 (?), 10:25, 24/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
По-хорошему pkg-config должен вызывать configure, а не make.
Редко используемой - потому что в Makefile вызывать $(shell) долго и дорого. Потом удивляются, почему сборка тормозит.
| | |
|
|
| 2.48, Аноним (-), 13:44, 24/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
проверил, к счастью код возврата выполняемой программы проверяется и все тормозиться если какой нибудь gcc вернул не 0
| | |
|
| |
| 2.51, anon2 (?), 00:46, 26/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
А что, сейчас игнорируются?))
Пробелы в путях к файлам в правилах нужно эскейпить, что, правда, вручную делать жутко не удобно.
Хорошо, что редко когда это нужно - всегда можно проект расположить в директории без пробелов в путях (на виндах можно сделать отображение директории на диск через subst), а пути к системным хедерам, пожалуй, встречаются только в опциях компилятора и автогенеренных dep-файлах зависимостей.
Если посмотреть на другие системы сборки, на то, как в них сделана обработка строк - например в cook от https://en.m.wikipedia.org/wiki/Peter_Miller_(software_engineer) - то в Gnu make сценарии сборки получаются "чище", легче читаются, чем в cook, именно из-за отсутствия необходимости эскейпить кавычки где-нибудь в регулярном выражении для вызываемого sed.
| | |
| |
| 3.52, yaa (?), 09:39, 26/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Если посмотреть на другие системы сборки, на то, как в них сделана обработка строк - например в cook от https://en.m.wikipedia.org/wiki/Peter_Miller_(software_engineer) - то в Gnu make сценарии сборки получаются "чище", легче читаются, чем в cook, именно из-за отсутствия необходимости эскейпить кавычки где-нибудь в регулярном выражении для вызываемого sed.
Зато регулярные выражения с $ внутри make --- $$$$ ;)
| | |
|
|
|
