|
2.9, Аноним (9), 12:14, 17/06/2019 [ответить]
| –4 +/– |
Gn — это интерпритатор неких скриптов, не знающих ничего ни о компиляторах, ни о флагах, ни о размещении либ. Вся эта информация хранится в скриптах, которые лежат внутри Хромиума. Хочешь собрать Хелло Ворлд, выкачивай исходники всего Хромиума. А потом еще и постоянно отслеживай, чтобы гугловцы ничего не ломали в этих скриптах, они то ничего не знают о твоем проекте и никому не гарантируют неизменность своих скриптов.
О да, лучшая сборочная система.
| |
|
3.22, Аноним (22), 13:21, 17/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Хочешь собрать Хелло Ворлд, выкачивай исходники всего Хромиума
Бред какой-то несешь. Каноничный и полный хелловорлд приводится самим же гуглом вот тут:
https://gn.googlesource.com/gn/+/master/tools/gn/example
> А потом еще и постоянно отслеживай, чтобы гугловцы ничего не ломали в этих скриптах
Как гугловцы поломают что-то в моих же скриптах? Опять-таки, в тебе говорит незнание матчасти и убежденность, будто нужны полные исходники хромиума. GN сам по себе минимален, все остальное (включая поддержку pkgconfig и тому подобное) лежит в дереве исходников хромиума. Копируй их себе в проект, удаляй всё, что тебе не надо, подправляй остальное под свои нужды, и всё -- ты независим от гугла.
| |
|
4.34, Аноним (34), 18:33, 17/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
А можно было бы включить наиболее востребованные скрипты в дистрибутив и поддерживать в них обратную совместимость… Хотя стоп, это же cmake получится.
| |
|
5.41, Аноним (22), 20:42, 17/06/2019 [^] [^^] [^^^] [ответить] | –1 +/– | Можно конечно Я вообще разработчикам предлагал в GN засунуть не только востребо... большой текст свёрнут, показать | |
|
6.56, Аноним (34), 10:30, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Во-первых, не надо передёргивать. Во-вторых, с rpm-макросами всё обстоит точно так же, как с модулями cmake: наиболее востребованные идут в комплекте, специфические поставляются вместе с соответствующим софтом.
| |
|
|
|
|
|
1.4, menangen (?), 10:50, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Пробовал, понравилась эта система сборки, но на продакшен так и не попала ни в одном проекте, увы. Её бы переписать на Go в один бинарник, это было бы интересно...
| |
1.5, Аноним (5), 11:10, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
помню, как тут все плевались с этого мезона. "Нинужно" и т.п.
а сейчас ничего - все пользуются
| |
|
2.7, Аноним (7), 11:41, 17/06/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Кто - все? Питон обязателен - значит "нeнужно". Я ещё не совсем спятил, чтобы заставлять пользователей ставить питон и зависимые либы только ради мезона.
| |
|
3.10, IRASoldier_registered (ok), 12:20, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
>Питон обязателен - значит "нeнужно"
Господи, ну считайте, что Python это just another ***sh. Башем-то пользуетесь, и не паритесь, что он установлен, ну вот и с Пайтоном так же кто мешает?
| |
|
4.13, Аноним (13), 12:34, 17/06/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
> ну считайте, что Python это just another ***sh.
Вот только не надо про то, что это shall. В Bash я могу быть уверен (как максимум, в двух ветвях - полноценный линукс или busybox). А в питонах, где ни запустишь, ловишь дичь какую-то из-за несовместимостей версий. Язык должен быть железным как bash или Ruby. Или, сразу, бинарный код.
| |
|
5.14, IRASoldier_registered (ok), 12:37, 17/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
>или Ruby
Вот не в курсе, что там у рубистов - у Ruby разве нет проблем с совместимостью версий? Или врут хейтеры, собаки?
| |
|
6.19, Аноним (-), 12:52, 17/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> у Ruby разве нет проблем с совместимостью версий
куда больше, чем у питона, вы с сумашедшим общаетесь, если он этого не осознает
| |
6.24, Аноним (-), 13:52, 17/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> у Ruby разве нет проблем с совместимостью версий? Или врут хейтеры, собаки?
Довольно редко. Обычно раз в 5-10 лет это происходит. Да и то, по мелочам.
| |
|
5.18, Аноним (34), 12:46, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> В Bash я могу быть уверен (как максимум, в двух ветвях - полноценный линукс или busybox).
В busybox нет bash, там ash. В минимальных установках ряда дистрибутивов тоже может не быть bash.
| |
5.32, Аноним (32), 17:39, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> В Bash я могу быть уверен
Ааааага. Давайте ка вы будете уверены в sh. А вот его жирненький дружочек bash таки разный от дистра к дистру. Где-то есть, где лежит не в том каком-то месте, а где-то его и нет (и это нормально).
| |
|
4.16, Аноним (34), 12:44, 17/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Башем-то пользуетесь, и не паритесь, что он установлен
Когда надо — паримся и пишем на POSIX shell.
| |
4.23, freehck (ok), 13:48, 17/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Господи, ну считайте, что Python это just another ***sh. Башем-то пользуетесь, и не паритесь, что он установлен, ну вот и с Пайтоном так же кто мешает?
Да, потому что shell для административных задач -- куда более удобный инструмент. shell-скрипты меньше по объёму и как правило более-менее хорошо написаны, в то время как любой python-скрипт огромен по размеру и склонен быть глюкодромом. И по-видимому, весьма много людей так или иначе столкнулись с плохим поведением python и хорошим поведением shell.
Это, безусловно, субъективный опыт. Если хотите, мы можем поспорить на тему python vs shell, и в процессе составить табличку плюсов и минусов. Это будет хорошая замашка на объективность.
| |
|
5.26, Gvd57uvx4 (?), 15:28, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Для себя взял за правило вотэтовот >>>
Bash использую до 40 строк.
Python использую от 40 строк.
| |
|
6.39, Аноним (39), 20:17, 17/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Тут больше от наличия/сложности логики зависит, чем от размера. Если нужно последовательно запустить 100 программ с параметрами, баш лучше подойдет, а если какая-то математика или работа со строками, то и от 40 строк на баше удавишься
| |
|
7.43, Аноним (34), 23:08, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> если какая-то математика или работа со строками, то и от 40 строк на баше удавишься
Это ещё смотря что за работа со строками.
| |
|
|
5.62, Аноним (34), 11:44, 18/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> shell-скрипты меньше по объёму и как правило более-менее хорошо написаны
Или ты ничего не понимаешь в шелл-скриптах, или просто не смотришь на скрипты, написанные другими. Большинство пишет их ужасно, потому что считает, что это просто, и учиться там нечему.
| |
|
6.67, freehck (ok), 15:57, 18/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Большинство пишет их ужасно, потому что считает, что это просто, и учиться там нечему.
Это специфично для программирования в целом. Подставьте вместо "shell" любой другой язык -- и это тоже будет правдой.
| |
|
|
|
3.30, Аноним (30), 17:28, 17/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Питон обязателен - значит "нeнужно".
Вообще, разработчики meson говорили пару раз, что чисто в теории можно и без python. Но есть два но... Сейчас система сборки еще не устаканилась и фичи постоянно добавляются, поэтому прямо сейчас отвязывать бессмысленно. Сами разработчики не заинтересованы в отвязывании от питона, но кто-нибудь другой может заняться.
| |
|
4.40, Аноним (39), 20:20, 17/06/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
А зачем отвязывать, чтобы усложнить разработку и повысить порог вхождения для контрибьюторов? cmake вон написали на крестах, получилась говнистая архитектура, в которой левая нога не знает, что правая делает, и нужно придумывать всякую дичь вроде generator expressions, чтобы это скомпенсировать
| |
|
|
|
1.6, Аноним (-), 11:35, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Чем вам configure && make && sudo checkinstall не угодил? Мало смузи?
| |
|
|
3.51, пох. (?), 09:05, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
учитывая удивительный мирок ./debian/ и странности современного rpm (не умеющего без лишних пинков банально собрать все указанные ему файлы уже установленные куда и как надо в пакет) - checkinstall нельзя назвать плохим решением. Если бы еще и поддерживался...
| |
|
2.15, Аноним (34), 12:41, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Это тебе они всем угодили. А нам не угодили libtoolize && autoconf && automake. Много сивухи.
| |
2.17, nobody (??), 12:44, 17/06/2019 [^] [^^] [^^^] [ответить]
| +6 +/– |
Лишних зависимостей маловато. Вот притянуть питон/руби/.NET/JRE/node.js/прочую-пoебень - наш выбор!
| |
|
|
4.21, nobody (??), 12:59, 17/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Это для разработчика только. Для потребителя autoconf не создаёт никаких лишних зависимостей, и в этом его killer-фича.
А вообще, сегодня 90% софта linux-only, так что там и autoconf обычно не нужен - gmake+sh вполне хватает
| |
|
5.29, пох. (?), 17:06, 17/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Это для разработчика только. Для потребителя autoconf не создаёт никаких лишних зависимостей,
> и в этом его killer-фича.
причем - даже если "потребитель" не такой уж и потребитель, и вполне способен поправить что-то в исходниках.
Пересобирать configure ему ради этого не потребуется.
Но манки-кодерков уже не остановить :-(
> А вообще, сегодня 90% софта linux-only, так что там и autoconf обычно не нужен
autoconf обычно нужен из-за неумения написать какой-нибудь build.sh (и можно даже обозвать его configure, как, к примеру, nginx) обрабатывающий --with-another-ненужнаяхня.
Ну не владеют обезьянки шеллом, не говоря уже про make, они только игого умеют.
| |
|
6.33, Аноним (34), 18:31, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> даже если "потребитель" не такой уж и потребитель, и вполне способен поправить что-то в исходниках.
Даже если потребитель и не правит ничего в исходниках, а просто хочет их собрать неканоническим образом, например, со статическими либами… А там libtool… И всё, приплыли, configure падает.
| |
|
7.35, пох. (?), 18:38, 17/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
у него все еще есть выбор - пропатчить достаточно простое место в сгенеренном makefile, или идти изучать дурацкий синтаксис.
в случае мезона выбора нет - даже если ты всего лишь хочешь собрать бинарник - хромую хрень тебе в src.
P.S. в целом же согласен - в отличие от самого autoconf, libtool - вредная и ненужная диверсия, не решившая никогда ни одной проблемы, для которых якобы была придумана, зато очень сильно изгадившая возможность ручного вмешательства в сборку.
| |
|
8.44, Аноним (34), 23:14, 17/06/2019 [^] [^^] [^^^] [ответить] | +/– | Так он не сгенерировался, configure же упал Чем он поможет libtool ломает логи... текст свёрнут, показать | |
|
9.49, пох. (?), 08:59, 18/06/2019 [^] [^^] [^^^] [ответить] | +1 +/– | в смысле упал Вообще не нашел библиотеку в нестандартном месте На самом дел... текст свёрнут, показать | |
|
|
7.47, souryogurt (ok), 02:51, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
А можно подробнее, как именно configure падает? Сам libtool не нужен для дистрибутива с исходным кодом.
| |
|
|
9.61, Аноним (34), 11:23, 18/06/2019 [^] [^^] [^^^] [ответить] | –1 +/– | Хотя нет, гоню Это было бы слишком просто для автодряни Скриптик libtool, ко... текст свёрнут, показать | |
|
|
|
|
5.48, Andrey Mitrofanov_N0 (??), 08:37, 18/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
#>> чем дич вроде autoconf
> Это для разработчика только. Для потребителя autoconf не создаёт никаких лишних зависимостей,
> и в этом его killer-фича.
Тише, тише!
Это же Разработчик. Да, он не умеет в автоконф, либтул, баш, си, сед, авк, ... всё вот это вот.
Такие нонеча разработчики. Субж во все поля...
| |
|
|
7.60, Andrey Mitrofanov_N0 (??), 11:23, 18/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Ретроград! Прогресс не остановишь!
Ну, что вы! Кто я такой, чтобы Ваш "прогресс" останавливать.
Вы и сами отлично справляетесь.
CMake, електрон, мейзон -- выкидывайте и переписывайте уже.
К нашим-то, к ретроградам, не примазывайтексь.
Дальнейших успешных сингулярностей Вам.
| |
|
|
|
|
|
2.46, Анонм (?), 02:50, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
1. Пока не придется разбирать эти портянки, которые трассируются очень плохо. За Meson не скажу, но с CMake проблемы решаются намного проще.
2. Язык оболочки ламповый, родной, но для чего-то кроме однострочников в интерактивном и эквивалентных им коротких скриптов он катастрофически ужасен.
3. make штука не самая быстрая
4. Checkinstall мертв, к сожалению. Но и когда был жив, часто проблем добавлял прилично (во всяком случае на не самых мейнстримных архитектурах)
| |
|
1.25, Ivan_83 (ok), 14:51, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
> Если раньше Meson отдельно сохранял CPPFLAGS и специфичные для языков флаги компиляции (CFLAGS, CXXFLAGS), то теперь они обрабатываются нераздельно и перечисленные в CPPFLAGS флаги применяются как ещё один источник флагов компиляции для языков, которые их поддерживают
Сомнительно, ИМХО может чтонить сломать
| |
|
2.45, Аноним (34), 23:16, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Что и как это может сломать? Я так понял, изменилось только то, как флаги хранятся в кеше, а компилятор в конечном итоге получит все те же самые.
| |
|
3.66, Ivan_83 (ok), 15:17, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
У меня CFLAGS и CPPFLAGS обычно разные, будет плохо если они смешаются в кучу.
| |
|
4.72, Аноним (34), 23:11, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> У меня CFLAGS и CPPFLAGS обычно разные, будет плохо если они смешаются в кучу.
Они всегда разные. И передаются компилятору именно что одной кучей. Как их при этом хранить — по отдельности или в месте — значения не имеет.
Дай угадаю: ты просто не знаешь, что такое CPPFLAGS?
| |
|
|
|
|
2.50, пох. (?), 09:02, 18/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
"это ж мне что - все исходники ВРУЧНУЮ перечислять в зависимостях?"
Не-не-не, вот прокатывающийся по ним скрипт, подбирающий весь мусор (включая пяток файлов, давно неиспользуемых) - это по нашему!
| |
|
|
4.63, нах_ (?), 13:01, 18/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
этот трэш - и осиливать незачем. Он gmake only да еще и нужна достаточно модная версия, в старых поломано кое-что.
make dep - там осиливать нечего (бонусом - что он обычно тоже нужен только один раз, при внесении изменений в дерево проекта, а не мелком патчинге) но список .c | .cxx от которых зависит итоговый бинарь он все же за тебя не соберет.
А этих .cxx в крупном проекте может быть с миллиончик.
| |
|
5.68, Аноним (34), 17:59, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> этот трэш - и осиливать незачем. Он gmake only да еще и нужна достаточно модная версия, в старых поломано кое-что.
И что же там gmake only? Шаблонные правила, разве что? Замени их суффиксными. Что ещё?
> но список .c | .cxx от которых зависит итоговый бинарь он все же за тебя не соберет.
А кто соберёт-то? automake не соберёт, cmake не соберёт, насчёт сабжа тоже сильно сомневаюсь.
| |
|
|
3.55, Аноним (55), 10:30, 18/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Давно было, написал универсальный makefile со всеми зависимостями, сам все находит строит зависимости, собирает. Не зависит ни от каких доп скриптов. Вообще делать с ним ничего не надо. Работает на любой системе, пихаю его везде. Таких лисапетов в инете давно полно. Нет, надо изобрести корявого глючного монстра.
| |
|
4.58, Аноним (34), 10:37, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Увы, такое реально только для hello world'ов. А если в проекте несколько библиотек и несколько бинарей, и у всего свои внешние зависимости, придётся таки чуть-чуть поднапрячься.
| |
|
5.59, Аноним (55), 10:49, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
есть и список внешних либ и свои промежуточные и цели сколько надо, достаточно просто. А проекты далеко не самые простые.
| |
|
|
|
|
|