Назовите хотя бы одну причину существования долбанного meson...

в загранах по дефолту используется польская нотация.

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

йотированные гласные пишутся, внезапно, через j

Это скорее «локальная» безграмотность конкретных чиновников,а не какой-то стандарт. У меня фамилия с такой гласной. И есть несколько знакомых с такими именами и фамилиями, но у них в загранпаспортах(современных) j нет. Хотя в 90х такое действительно попадалось. Ну так экс-советские граждане,и чиновники в том числе, вообще не отличались знанием иностранных языков.

при подаче заявления можно указать правильное (желаемое) написание имени и фамилии

Да, это правда, и я даже знаю человека который этим воспользовался. У него сложная для транслитерации фамилия,поэтому разные ведомства в разных документах пишут ее «как Б-г на душу положит» и ему приходится чиновников поправлять чтобы потом не иметь проблем из-за несоответствия фамилии в разных бумагах.

нет, это не «локальная безграмотность». это официально используемая нотация. идиотская, да. но если ты не напишешь им, как надо писать твоё ФИО в транслите, они его напишут в польской нотации, с этими j и прочим.

они его напишут в польской нотации, с этими j

Друг получал загранпаспорт в позапрошлом году. Его фамилию через j не написали,хотя она такая что могли(как раз таки польская и по-польски пишется именно с j). Так что нет - писать непременно через j это не жесткое требование. Но он оформлял документы в Питере где вероятно чиновники более грамотные. А где-нибудь в областном райцентре пожалуй что и не такое написать могут ибо языков не знают.

Кстати, нотация не то чтобы «польская»,это так называемая «славянская латиница», на нее даже какой-то древний стандарт ISO есть. Древнесоветский гост как раз с него слизан. Поэтому j встречается не только в польском но и других славянских языках,использующих латиницу (чешский например). И как ни странно - у главных любителей стандартизации и порядка - немцев,когда они пишут в документах славянские фамилии. И,кстати, j всё еще любят писать в той соседней стране которую нынче называть нельзя и откуда происходят мои предки потому и куча родственников там. А вот у англичан при написании славянских фамилий «й»==«y»,поэтому «я»==«ya» и так далее. А на конце фамилий типа «-ий» они вообще одно i часто пишут. И часто - женские фамилии в мужском варианте без «-а» на конце (немцы тоже). У французов как я уже говорил транслитерация вообще заумная, много лишних букв добавляется,хрен прочитаешь:) А так как официальным языком дипломатии и международного делопроизводства довольно долго был французский то и наши так писали. К тому же в международных автоперевозках традиционно использовался французский,поэтому в водительских правах надписи на нем есть. А лет десять назад решили упростить,причем по инициативе ICAO (авиаторы),а не наша местная блажь. Даже приказ ФМС на эту тему был,номер конечно не назову. И вместо «й»==«y» стали писать «i»,соответственно и «ya» стало «ia». Даже твердый знак ъ стали обозначать - ie. Владельцам «старых» иностранных документов добавили конечно головной боли в случае обмена заграна на новый,но в будущем всё-таки попроще с этим будет. У меня тут до границы (с финнами) полсотни километров,так что тема оформления документов долгое время была весьма актуальна для многих. И казусов немало случалось.

мдя... иногда даже сложно предположить, что они там курят, чтобы писать ia вместо ya, например. и уж что их сподигло так зашифровать твёрдый знак - это вообще загадка. я подозреваю, что это «ери» и «яти» из древнеславянского. который, конечно же, никто не знает. да и произношение у них было вообще другое, не похожее на современный русский язык и к твёрдому знаку отношения не имевшее. в общем, как всегда: бессмысленно и беспощадно.

сложно предположить, что они там курят

Тем не менее эти курильщики (ICAO) - из «развитых цивилизованных стран»,а не наши как можно было бы подумать. Видимо дури везде хватает:) Ну и имитацию английскими буквами звучания славянских фамилий они вроде как должны бы лучше нас знать - всё же там скорее всего были и носители английского. Кстати, с транслитерацией английских фамилий в русский - бардака не сильно меньше,да и то только потому что у них фамилии попроще звучат. Почему например паровую машину изобрел Уатт,но приятель знаменитого сыщика - Ватсон.

Вот полезную ссылку подсказали: https://transliteraciya.ru/familii/ Порядок таки постепенно наводят,руководящие документы изданы.

«развитые страны» не обязательно англоговорящие. а «ia» читается как «иэ» (например Ian - Иэн), но никак не как «я» или хоть что-то, похожее на русский язык.

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

имха

фонетическая эквивалентность не есть первоочередная цель в международных документах

там скорее взаимо-однозначное соответствие между региональной и служебной записью при наличии указания региона

т.е. (возможно) одна и та же (без учёта региона) служебная запись отобразится в разные регионы(да одинавом алфавите) в разные как слова так и звуки

попытка максимизировать до 99% сохранения фонетики требует использования фонетического международного алфавита который ширше классических 26 глифов да и от человека за стойкой ожидать прохождение (китайского) экзамена на знание такового не соотвествует духу эпохи

Вот вы объясните мне, какие силы зла забанили вас в гугле яндексе?

https://www.gosuslugi.ru/help/faq/foreign_passport/100359

Как пишутся ФИО в загранпаспорте

Имя и фамилия в загранпаспорте автоматически транслитерируются — русские буквы заменяются латинскими
Текущие правила транслитерации соответствуют нормам ИКАО — Международной организации гражданской авиации. Россия перешла на этот стандарт в 2014 году

Скажите, где вы работаете, что бы ненароком, туда же не устроиться?

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

Указываю новые CFLAGS, CXXFLAGS, запускаю meson setup – reconfigure с новым buildtype, запускаю ninja, И НИЧЕГО НЕ ПЕРЕСОБИРАЕТСЯ!!! Только линковка запускается повторно!

Мезон не отслеживает изменения в переменных окружения. Если хочешь, чтобы он тебя лучше понимал, то передавай ему флаги вот так: meson -Dc_args="$CFLAGS" --reconfigure. Правда, сейчас и это не работает… но пофиксят: https://github.com/mesonbuild/meson/issues/7325

Чем это лучше autotools, который им заменяют в конце-то концов

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

Да напиши Makefile и не парься. Все эти мезоны и ниндзи только для неосиляторов make-а. Проблема сборки проектов решена 50 лет назад, не надо ничего выдумывать.

Да уж конечно. &: для параллельной сборки, появился только в GNU make 4.3. Функцию intcmp для работы с числами, добавили только в GNU make 4.4. Я не зря указываю, что речь именно про гнутый мейк, так как в БСДшном даже это появится лет через 100. Хорошо, конечно, что гнутые сподобились таки базовый функционал добавить, но поздновато.

зело плюсую. понаписали велосипедов, которые приходится выдирать и переписывать на Makefile’ы. я уже даже думаю написать софтину, которая будет эти говноконфиги в Makefile’ы переделывать автоматом.

А, мейковский бэкенд для мезона? Напиши, чо. А то ведь сейчас только в нинжу конвертят… В мейк - тоже неплохо будет. :)

Будет, см. главу "4.14 Generating Prerequisites Automatically " в руководстве GNU make, а также флаги -MD

Ага, ага… А чтобы на первом проходе, когда .d файлов ещё нет, всё ни зафейлилось, подключаем их через -include, чтобы проигнорить ошибки. :)

Да и примеры у тебя… билд дир захардкодил, ладно бы ещё через vpath. Хотя с ним тоже гемора - до задницы.

будто все остальные системы сборки, каковых немало в опенсорце, не находят сами пути до зависимостей. и вообще, для этого в дистрибутивах есть pkg-config и проблем ни у кого не было до сих пор.

Так и мезон же через пкг-конфиг работает.

Тоже не понимаю, зачем нужен meson. Ведь есть bazel.

То есть, питона нам мало - яву затащим ради сборки!

зачем? месон на пистоне. зачем это поддерживать? это надо выбрасывать.

врочем, он уже поделен на ноль: см. выше мой пост про muon + samurai. это не решает глобальную проблему кривых говноконфигов месона и их зависимостей от версий, но хотя бы устраняет пистон и необходимость переписывания этого мусора во что-нибудь приличное. уже большой плюс. ну и работает это на порядки быстрее.

А так, meson вполне удобен. Мне нравится. Гораздо лучше автолулзов и даже cmake.

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

зачем?

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

но хотя бы устраняет пистон и необходимость переписывания этого мусора во что-нибудь приличное.

Зачем переписывать? У него встроенные кодогенераторы, которые сами переписывают мезоновский рецепт, например, в нинжу. Можно и в мейк, просто пока не реализовали. Вот, думал, ты и сделаешь…

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

переписывать нужно было, чтобы на машине не было пистона.

Да он сам себя переписывает, гарантирую! Запусти ему configure и потом удали пистон нафиг. Ничего не изменится, так как рецепт будет уже в нинжу переведён.

одно говно в другое? я уже спросила: зачем? когда можно всё это убрать, оставить только сишечку. и тогда останется только проблема говноконфигов, но это уже позже можно как-то будет решить.

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

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

одно говно в другое? я уже спросила: зачем? когда можно всё это убрать, оставить только сишечку. и тогда останется только проблема говноконфигов, но это уже позже можно как-то будет решить.

Да мы будто на разных языках разговариваем. :) Что ты под «говноконфигом» подразумеваешь? Файлы meson.build? Ну так когда ты ему configure запускаешь, то он ЕГО и переписывает в нинжу. Потом meson.build можно стереть, можно и питон снести - всё будет работать.

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

это надо убирать всё, под корень. и заново писать конфиги. это печально, но факт. если даже разработчики не понимают, как они навредили своим проектам, вкорячив это убожество, то куда уж дальше-то.

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

да, а нинзя - это, внезапно, опять говнопистон.

Чуть со стула ни упал от удивления… Но нет, это не так:

$ file `which ninja`
/usr/bin/ninja: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bf49052ef891fc000c6c3a42a807046d249fea63, for GNU/Linux 3.2.0, stripped

если даже разработчики не понимают, как они навредили своим проектам, вкорячив это убожество, то куда уж дальше-то.

Ну кто как. Некоторые разрабы жалуются, а каким-то и понравилось. Гном - так тот вообще целого разраба отрядил мезон патчить под свои нужды, и норм им теперь. dosbox-staging перешёл, и все довольны. А на форумах dosemu постоянное нытьё, типа, мы столько патчей в апстрим влили, а всё равно это какое-то дерьмо. Так что везде по-разному.

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

С кросс-компиляцией у них реальное днище, и, судя по всему, фиксить не будут. Если бы ни этот факт, я бы, в целом, позитивно к месону относился.

не надо падать со стула. ты на пакет этой фигни посмотри. попробуй это УГ собрать без пистона на машине, для начала. это только начало. с какого фига софтине на плюсах впился пистон вообще? вот не нужен такой софт.

я в третий раз пишу, что есть samurai, который собирается без пистонов и всякого ненужно. и работает быстрее.

Правда, сейчас и это не работает…

Просто вишенка на торте...

попробуй это УГ собрать без пистона на машине,

https://github.com/ninja-build/ninja/blob/master/README.md

You can either build Ninja via the custom generator script
written in Python or via CMake.

Ну то есть без питона таки можно собрать. Но почему-то у них 2 системы сборки параллельно, и 1 из них - самописная на питоне. Это, в общем-то, мега-странно. Но покуда есть и симейк, можно особо не переживать.

я в третий раз пишу, что есть samurai, который собирается без пистонов и всякого ненужно. и работает быстрее.

Да я понимаю, понимаю. Просто я пробовал мюоном пособирать реальные мезоновские проекты, и он не всё собирает.

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

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

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

На meson переходят с GNU Autotools, мотивацию понять можно...

https://github.com/XQuartz/xorg-server/blob/server-1.13-branch/configure.ac

https://github.com/XQuartz/xorg-server/blob/master/meson.build

а он не всё собирает, потому что от версии к версии это говно ещё и несовместимо само с собой. я об этом тоже тут выше писала. там тупо разные(!) форматы конфигов. это ещё фигня, потому что пистоны меж собой тоже часто несовместимы. потому что писали это всё макаки и для макак. и это нельзя использовать от слова совсем.

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

нет. нельзя.

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

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

Назовите хотя бы одну причину существования долбанного meson…

Ну хотя бы чтобы я мог собрать ccid-1.6.2 выполнив:

meson setup builddir
cd builddir
meson compile
sudo meson install

тем самым получив возможность подписывать отправляемые в налоговую отчеты своим ЭЦП 3220 прямо из линукса.

А чем лучше держать всякие perl, m4 на машине, чем питухон?
Речь не идёт о пакетных менеджерах вроже pip, а о самом cpython, возможностей которого вполне хватает на создание даже очень сложной билд системы с нуля. waf вроде бы даже на python 2.5 должен запускаться, при этом умеет делать то же, что и автотулзы, притом гораздо быстрее (в отличие от meson, которого обделили базовыми вещами). Да, язык переусложнён, особенно с 3 версии, но присутствует практически во всех системах, где его специально не выпиливали и прекрасно справляется с обработкой текста ( вт.ч генерация кода), запуском процессов, взаимодействием с сишным кодом.
Насчёт же тяжёлрсти современного питухона - да, это не приятно, но нынче без него нельзя собрать даже mesa (там кодген на нём).
Отказываться от открытых драйверов на GPU? Ну кто-то может и может себе позволить, но в контексте глобального отказа от 2д ускорения сейчас это означает остаться с тормозной и неэффективной системой. Возможно, я бы хотел форк mesa без meson и llvm, работающий без glvnd, с classic драйверами и отдельной реализацией gbm, при этом достаточно тестируемый и всё ещё забирающий полезные изменения с апстрима, но это нереально - кто-то это всё должен поддерживать фуллтайм и тестировать на куче железа. К сожалению, всякие редхатовцы и фридесктоп, получающие финанисрование на эту всю разработку и тестирование, имеют python и llvm на любой машине и даже принудительное требование llvm только доя компиляции шейдеров на этапе сборки считают нормой. А на source-based дистрибутиве это может потребовать до нескольких суток компиляции в зависимости от CPU и памяти.

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

Я бы не рискнул утверждать, что авторы QEMU ничего не знают про кросс-компиляцию. Но, правда, они тоже отрядили 1 разраба патчить мезон под себя. Хотя даже это им не помогло, и у них теперь смесь мейкфайлов и мезона, при чём первые вызывают второй. :)

Глобально, проблема мезона сейчас только одна: кол-во его разрабов не соответствует спросу на продукт. В результате, тысячи багрепортов висят без ответа, сотни пулл-реквестов, и тд и тп. То есть, спрос на проект - гигантский. Но его пилят «полтора землекопа», и они не могут удовлетворить спрос, из-за чего проект постепенно скатывается.

ты не сможешь работать с их «ЭЦП» без проприетарщины. и никаких подвижек в сторону опенсорца они не делают.

включая кросскомпиляцию

В Windows я делал кросскомпиляцию, но без сложностей, что там не так?

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

Видимо им показалось что это не так страшно, как поддержка сборки с помощью GNU Autotools.

ты не сможешь работать с их «ЭЦП» без проприетарщины. и никаких подвижек в сторону опенсорца они не делают.

Эм, а в чем проблема использовать rtPKCS11ecp от Рутокена который является производителем этой самой ЭЦП? И браузер Chromium-Gost с ГОСТовским шифром?

Если хотите все опенсорсное - начните с опенсорсной флешки. Для меня опенсорс и проприетарщина это просто сорта бананов.

он её не поддерживает, например. выше писали. но это уже разбирательтства в сортах. я этим заниматься не хочу. я уже давно выпилила пистон и всё работает нормально. но с этой заразой в виде месона пришлось изрядно потратить время. однако, с работающим muon и samurai этот вопрос закрыт. не решён, но хотя бы заткнут временным решением. остались проблемы несовместимости версий и кросскомпиляции, это решение только для подмножества C/C++, но у меня другого софта и нет, так что можно забить. а дальше уже не моя зона ответственности. бороться с такими вещами надо не на уровне систем сборки, а на уровне написания самих пакетов софта. со стороны сборки ничего не исправить.

вот я про флэшку и говорю. я когда-то закидывала удочку пейсателям этих «ключей». они даже не чешутся насчёт опенсорца. там всё глухо, как в танке. ну а браузер «хромиум гост» это вообще жёсткое порно.

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

он её не поддерживает (кросскомпиляцию), например. выше писали.

Кто читал, дайте ссылку.

Питоны вполне совместимы между собой, если не использовать смузи-нововведения.
Вот из документации waf:

Building Waf requires a Python interpreter having a version number in the range 2.6-3.5. The source code is then processed to support Python 2.5.

Документация немного устарела, на последнем питухоне всё, разумеется, работает.
2.5 релизнулся в 2006 году, так что бояться, что попадётся система его не поддерживающая (не обновлявшаяся с 2006 года), думаю, не стоит. А вот система в которую намеркнно не включили хоть какой-то питухон - сейчас довольно редкий случай, но чаще всего это какой-то эмбеддед.
Проблема не в инструменте, а в макаках, пытающихся их использовать без должной компетенции.
Да, синтаксис питухона создаёт низкий порог вхождения, чем притягивает макак, но я не могу сказать, что он сильно хуже того же makefile, в котором тоже отступы и переносы являются частью синтаксиса. Оба - плохой пример синтаксиса.

он её не поддерживает, например. выше писали.

Если про меня речь, то я не говорил, что совсем не поддерживает. Вот мюон, как раз, совсем не поддерживает. А в мезоне её поддержка, номинально, есть. Только вот заключается она в том, что юзер должен предоставить отдельный файлик с захардкоженными именами тулзов для кросс-компиляции. После чего, вызовы find_program() и аналогичные - перестают что-либо искать, и начинают тупо возвращать имена из этого файлика. И это нельзя привязать к отдельно взятому подпроекту (только глобально ко всему проекту), и нельзя использовать одновременно с хостовой компиляцией (месон переходит в режим кросс-компиляции, и про хостовые сборки больше ничего слышать не хочет). Это совершенно тупо, так как в этих файликах нельзя даже захардкодить альтернативы, типа, не знаю там, i386-gcc|i686-gcc например. Уж не говоря про более продвинутые вещи, типа clang --target.

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

Если обратить внимание, что авторы qemu допустили в своём проекте смесь мейкфайлов и meson, а ранее допустили glib, то всё встаёт на свои места - в проекте кромешный бардак. Именно по этому несмотря на наличие jit, qemu, не будучи точным потактовым эмулятором, не способен в адекватную произврдительность. glib в несвязанном с gnome/gtk проекте (опциональный gui на gtk не считается) - в принципе признак кромешного бардака в нём

это фактически и означает «не поддерживает».

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

Мировая практика, не? https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-comp...

Это совершенно тупо, так как в этих файликах нельзя даже захардкодить альтернативы.

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

Не мировая практика, а симейковый рак.

И это нельзя привязать к отдельно взятому подпроекту (только глобально ко всему проекту)

Что бы линковать x86 библиотеки к aarch64 коду?