Опубликован релиз сборочной системы Meson 1.7.0, которая используется для сборки таких проектов, как X.Org Server, Mesa, QEMU, Lighttpd, systemd, GStreamer, Wayland, GNOME и GTK. Код Meson написан на языке Python и поставляется под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62623
Поддержку C++ модулей когда-нибудь добавят?
В xmake есть
xmake тоже кстати D поддерживает
Причём тут сборочная система Meson? Ах да! В Паскале есть модули.
Да, тоже жду, когда паскаль добавят
Боже, смотрю на это и думаю, как же здорово работать с дотнетом, где нету вот всех этих десятков сборочных систем и постоянной миграции с одной на другую
Кто вам говорит, что миграции постоянны?
с++ разработчики жалуются, говорят, что у них на каждый проект по своей сборочной системе написано.Андроид-разрабы жалуются на градл-мавен, который сам поломался-сам починился.
JS "разрабы" переписывают по кругу с Webpack на Vite на Parcel на Rollup на Esbuild
Python "разрабы" вообще невдупляют
У одних нас, дотнетчиков, простой как палка dotnet, который уже лет 8 не менялся
Скоро dotNet как Cobol закаменеет
У Rust вменяемый тулинг из коробкиУ Golang вменяемый тулинг из коробки
Вот где сразу видна разница между инструментом для работы и творчеством гаражников.
> Вот где сразу видна разница между инструментом для работы и творчеством гаражников.И вы это написали, конечно, используя ос, софт и либы на этом всем? Работу видно по результату так то.
У них на каждого по хозяину. Язык прибит к одной конторе, и больше нет желающих пилить реализацию.Тут видна разница между востребованным инструментом и навязываемым.
> Тут видна разница между востребованным инструментом и навязываемым.Dotnet, Rust, Golang - востребованные инструменты, тут ты прав
> У Golang вменяемый тулинг из коробкиЭто который требует использовать URL в сети для импорта,
кеширует когда не надо, а когда надо нет.Требует от репозитория соответствия идеи языка?
Ну странно для вменяемого тулинга.
А да еще засирает indirect зависимостями и не вычищает их после себя.
Сомнительно сомнительно.
> Python "разрабы" вообще невдупляютНевдупляют что? Накой скриптовому языку билд-система?
Зачем языкам вообще билд-система? Таковая рождается из неполноценности языка.
Все вдупляют уже давно есть pip, poetry, а сейчас подезжают и
новыенькие подклки.В том числе и на божественном Rust на который уже надр$ают всем миром.
>> Python "разрабы" вообще невдупляют
> Невдупляют что?ты пейфон разраб, что-ли?
"JS "разрабы" переписывают по кругу с Webpack на Vite на Parcel на Rollup на Esbuild"Смешались в кучу кони, люди. Vite использует и rollup и esbuild для разных целей. Переводят проекты с webpack либо шаблонов на нем основанных на vite. Получают значительное упрощение конфигурации, уменьшение числа зависимостей, ускорение сборки и поднятия локального проекта.
Я думаю от ускорения запуска и сборки дотнет проекта в десятки раз + уменьшения числа зависимостей вы бы тоже не отказались.
> Я думаю от ускорения запуска и сборки дотнет проекта в десятки раз + уменьшения числа зависимостей вы бы тоже не отказались.Дожились 😅😁
Статически-типизированный Dotnet компилируется быстрее чем JS. При этом основное приемущество JS - отсутствие компиляции 😆😆😆
"быстрее" всётаки надо проверять, все проекты на dotnet что я видел запускались на порядок медленней современных vite проектов. Да и чистый JS мало кто использует.
> "быстрее" всётаки надо проверятью...Зачем? У меня есть три основных проекта, они собираются за 5-10 секунд каждый после git clean -dfx.
Это при учёте, что кеш nuget-пакетов выгружен из сети, а так же что вообще никаких оптимизаций сборки не было
Ему просто надо на что-то пожаловаться. Не видишь, что ему так хочется найти оправдания и дальше сидеть на игле микрософта? Он просто себя так успокаивает.
Зато есть десяток версий дотнета и .core c безумной фрагментацией. Спасибо, жрите сами.
> Зато есть десяток версий дотнета и .core c безумной фрагментацией. Спасибо, жрите
> сами.хз, 10 лет с дотнетом работаю, с такими проблемами не сталкивался. Можешь подробней рассказать?
Примерно вот такие проблемы.https://stackoverflow.com/questions/72322257/migrating-from-...
А до этого ещё Web Forms были на которые микросфот вроде тоже забили.
Как забили? А что вместо них?
> забили...с 10 декабря 2024 года: https://devblogs.microsoft.com/dotnet/introducing-winforms-a.../
То есть, получается, уже целых два месяца как забили.
Работа на 4 часа, в особо упоротых случаях на день работы. Есть еще?
с VB переехать на C# это у вас на 4 часа:)
а может managed C++ на линуксе тоже магете?
> с VB переехать на C# это у вас на 4 часа:)автогенератор c# из VB есть, это же CLR.
> а может managed C++ на линуксе тоже магете?
не, с крестами пусть опущеные работают
я думаю вы уже поняли что проблем с миграцией у МС куда больше чем работы на 4 часа о которых вы тут писали. у МС такое чувство меняется покаление индусов и клепают новый фреймворк забивая на старый. где сильверлайт сейчас не подскажите?
> я думаю вы уже поняли что проблем с миграцией у МС куда больше чем работы на 4 часа о которых вы тут писалиКуда меньше чем с крестами или, упаси боже, JS. С пейфоном не сравниваю потому что там обычно выкидывают весь код и с нуля переписывают
> где сильверлайт сейчас не подскажите?
там же, где и Flash
я как то переписывал проект с managed C++ на C++/CLI. Благо проект был не большой но про тулзы автогенерации и 4 часа может говорить только человек который ими либо не пользовался либо проект был совсем на 3 строчки.
> про тулзы автогенерации и 4 часа может говорить только человек который ими либо не пользовался либо проект был совсем на 3 строчки....либо человек просто звездун.
> я как то переписывал проект с managed C++ на C++/CLIя как-то переписывал проект с c++ на c#. Ты чего сказать-то хотел?
А 3rd party зависимости как быстро перепишите с asp.net на core?
> А 3rd party зависимости как быстро перепишите с asp.net на core?Ну мы месяца за полтора весь код перевели на кор, со всеми зависимостями. Но у нас более ста проектов было и мы не отрываясь от основной работы делали
и с webforms перелезли? вы просто молоды. web forms было проще прибить чем с него мигрировать кудато. возможно MS исправилось и не генерирует новые ферймворки как пирожки сейчас. но раньше без работы програмистов не оставляли на долго. а что на декстопе было это просто ад. многие на java и уходили т.к. там стабильность в АПИ куда большая и не нужно асбуку учить каждые 5 лет занова.
> и с webforms перелезли?а мы и не пытались
> возможно MS исправилось и не генерирует новые фрeймворки как пирожки сейчас
генерирует. это плохо? Просто пользуйся проверенными фреймворками
> оставляли на долго. а что на декстопе было это просто ад.
winforms, wpf, ничего не меняется уже лет 10
> многие на java и уходили т.к. там стабильность в АПИ куда большая
в каком месте апи у дотнета нестабильно?
> и не нужно асбуку учить каждые 5 лет занова.
Что заново учить? Ткни пальцем. Выглядит как будто ты преувеличиваешь
Что, переписали все 15 строчек?
> Что, переписали все 15 строчек?Чел, мы в 2025 году живём. Если у тебя на сипипи всё очень медленно и плохо, то это не означает, что у других так же.
Я реально видел как 20 разработчиков c++ не смогли поддерживать рядовое серверное приложение потому что не смогли разгрести свой "оптимизированный" код, который просто не работал.
Я время экономлю своё, поэтому беру c#/docker и не парюсь. Да, у меня перевести проект на VB с дотнета на дотнет-кор это четыре часа. Да, у тебя один пук на сипии стоит недели разработки.
Ты ездиешь на раздолбанном москвиче, я езжу на бмв, если сравнивать
Давайте теперь сравним зарплаты. И кажется что неделю делать пук на Сипипи выгоднее.
> Давайте теперь сравним зарплаты. И кажется что неделю делать пук на Сипипи
> выгоднее.Сравни, отпишись
> Боже, смотрю на это и думаю, как же здорово работать с дотнетом, где нету вот всех этих десятков сборочных систем и постоянной миграции с одной на другуюА откуда им взяться в технологии, прибитой сугубо к Винде? Так-то и разработчики C++ под Винду еще с 90-х юзают Visual Studio и горя не знают.
core .net кросплатформены. вы отстали от жизни лет на 10)
> А откуда им взяться в технологии, прибитой сугубо к Винде?я винду около года не включал. Вся разработка это fedora+docker+rider+dotnet. ЧЯДНТ
> я винду около года не включал. Вся разработка это fedora+docker+rider+dotnet. ЧЯДНТСобственно вот это. Шестерки майкрософта намного лучше смотрятся - в винде. А тащить свой маздай и его методы в линух - может вам еще и спасибо сказать?
>> я винду около года не включал. Вся разработка это fedora+docker+rider+dotnet. ЧЯДНТ
> тащить свой маздай и его методы в линух - может вам еще и спасибо сказать?Чего тащить? dotnet устанавливается в домашнюю папку пользователя и не требует никаких зависимостей.
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-i...
В чём плюс то?
Вы прикованы на мертво к венде, а за её пределами ваш диалект хоть и можно запустить но он никому не нужен.
> В чём плюс то?
> Вы прикованы на мертво к вендеНет, дотнетчики сейчас в основном с маков работают
> Нет, дотнетчики сейчас в основном с маков работаютПрикольная фронда у майкрософта случилась. Но как известно от смены рабовладельца результат не меняется.
> Боже, смотрю на это и думаю, как же здорово работать с дотнетом, где нету вот всех этих десятков сборочных систем и постоянной миграции с одной на другуюНу есть одна, которую тоже надо настраивать.
Никто не мешает выбрать одну систему сборки и ее использовать.
> Никто не мешает выбрать одну систему сборки и ее использовать.но это не работает. Собрать c/c++ проект руками для того, чтобы его просто запустить - это самое настоящее приключение, в котором в конце ты упираешься в то, что у тебя операционная система неправильной версии (!)
С такой философией можно сказать: как вы можете ездить на машинах когда их столько моделей и марок существует, вот троллейбус - он один... Хз, мне показалось или у тебя кризис и ты пытаешься найти хоть что-то позитивное в дотянете? Он же по факту сейчас сейчас совсем не конкурентен и новых проектов на нем не рождается...
> Он же по факту сейчас сейчас совсем не конкурентен и новых проектов на нем не рождается...а мужики-то и не знали
Шёл 2025 год, Илья гордился тем, что работает в экосистеме Windows.
Шел 2025 год. Эксперты opennet начали догадываться, что java'у можно запустить не только на sun solaris...
расскажи это ребятам, которые пытаются unity скомпилировать ;)
Кроме Make ничего не нужно.
Почему? Да потому что все эти хипстерские билд стстемы тупо не умеют фиксить зависимости. Make тоже не может, но мейк это стандарт.Вот скачал я очередной проЭкт с хаба, мало того что там окажется очередная васянская билд стстема, так еще и все зависимости придется самому ручками ставить/билдить. И нет бы положить сорцы всех библиотек прямо в архив, так нет, потрать целый день на поиски ОПРЕДЕЛЕННОЙ ВЕРСИИ библиотеки.
Если уж тащите мне в систему гору г*вна, уж сделайте так чтобы я ввел одну команду и оно само сбилдилось и установило все зависимости
вы за какие проекты говорите? llvm neovim собираются в однострочник
> Make тоже не может, но мейк это стандартMake - это огрызок, абсолютно бесполезный вне юниксового окружения с coreutils.
> И нет бы положить сорцы всех библиотек прямо в архив, так нет, потрать целый день на поиски ОПРЕДЕЛЕННОЙ ВЕРСИИ библиотеки
Абсолютно все современные билд системы (в т.ч. сабж) для C и C++ могут скачать и собрать любую либу, необходимую для проекта. Так что тут уже вопросы сугубо к автору проекта с хаба, а не к билд системе.
> Make - это огрызок, абсолютно бесполезный вне юниксового окружения с coreutils.Нет.
Во фре свой bmake и никакого coreutils оно не требует.
Кажется и gmake линуксовый coreutils тоже не требует, но я не уверен.
> Абсолютно все современные билд системы (в т.ч. сабж) для C и C++ могут скачать и собрать любую либу, необходимую для проекта. Так что тут уже вопросы сугубо к автору проекта с хаба, а не к билд системе.Я хз что на это ответить.
С одной стороны да, технически это возможно.
С другой так редко кто делает, потому что даже в случае сборки из CMake другого CMake проекта это не очень гладко происходит, а если там другая сборочная система то это скатывается до уровня шелл скриптов.
>> Make - это огрызок, абсолютно бесполезный вне юниксового окружения с coreutils.
> Нет.
> Во фре [...] не требует.
> gmake линуксовый [...] тоже не требуетЧто "нет"? Где ты увидел в исходном сообщении слово "требует"?
Речь шла о том, что make целиком и полностью работает с внешними утилитами, и без оных из coreutils ты даже файлик не сможешь удалить, копировать, переместить.
>> все современные билд системы [...] могут скачать и собрать любую либу
> С другой так редко кто делаетВ Cmake так делают все.
> даже в случае сборки из CMake другого CMake проекта это не очень гладко происходит
Что ты конкретно имеешь в виду? Хоть один пример.
> а если там другая сборочная система то это скатывается до уровня шелл скриптов.
Какие еще шелл-скрипты в CMake? Зачем?
> Я хз что на это ответить.
Если не можешь сказать ничего конкретного, то лучше действительно не отвечать.
> Речь шла о том, что make целиком и полностью работает с внешними утилитами, и без оных из coreutils ты даже файлик не сможешь удалить, копировать, переместить.Нет во фре в базе кореутилс, а файлик удалить можно :)
> В Cmake так делают все.Я видел чтобы вобирали левые либы всего несколько раз, один раз оно было надо чтобы получить доступ ко внутренним структурам. OpenToonz.
Подавляющее большинсов просто проверяет что нужные либы уже есть в системе и фейлится если нет или отключает какие то опции если оно опциональное.
> Что ты конкретно имеешь в виду? Хоть один пример.То и имею ввиду.
Если ты в CMAke добавляешь сборку зависимости которая собирается хотя бы мезоном то это будет мало чем отличатся от того чтобы написать шелл скрипт который будет собирать нужное по очередли просто дёргая обычные комманды для сборки.
Некоторые в таких случаях пишут для чужих либ свои cmake файлы.
> Нет во фре в базе кореутилс, а файлик удалить можно :)Не разводи цирк. Ты прекрасно понял, что речь шла о юниксовых утилитах типа rm, cp, mv и т.п., вне зависимотси от того, опакечены они или идут в базовой системе.
> Подавляющее большинсов просто проверяет что нужные либы уже есть в системе и фейлится если нет или отключает какие то опции если оно опциональное.
Если стоит задача использовать системные либы - да, проверяют либы в система. Неожиданно, правда? А когда есть задача собирать их локально как часть проекта (о чем и идет речь в в этой ветке), то они интегрируются в систему сборки.
> Если ты в CMAke добавляешь сборку зависимости которая собирается хотя бы мезоном то это будет мало чем отличатся от того чтобы написать шелл скрипт который будет собирать нужное по очередли просто дёргая обычные комманды для сборки.
Еще раз: если я подключаю к CMake проект на meson, накой мне шелл скрипт? Ты вообще о ExternalProject_Add() слышал?
> Не разводи цирк. Ты прекрасно понял, что речь шла о юниксовых утилитах типа rm, cp, mv и т.п., вне зависимотси от того, опакечены они или идут в базовой системе.Так ты просто линуксойд и не понимаешь что жизнь без coreutils для многих обыденность, а тебе оно мастхэв.
Вот и всё.
> А когда есть задача собирать их локально как часть проекта (о чем и идет речь в в этой ветке), то они интегрируются в систему сборки.Ну вот я такое считанные разы видел.
> Еще раз: если я подключаю к CMake проект на meson, накой мне шелл скрипт? Ты вообще о ExternalProject_Add() слышал?К тому что твой ExternalProject_Add() мало чем отличется от того если бы автор положил шелл скрипт который бы в начале собрал все зависимости их родными сборочными системами а потом дёрнул cmake собрать основной проект.
И я помню только один проект на CMake где внутри собирались чужие либы.
На самом деле есть ещё аддоны для коди с эмуляторами, но там можно сказать что основно проекта и нет совсем, CMake там просто обёртка-прокси для сборки эмуляторов.Те мой спич к тому что всегда такая сборка это какие то костыли и проще этого избегать пока совсем других вариантов не останется.
> Так ты просто линуксойд и не понимаешь что жизнь без coreutils для многих обыденность, а тебе оно мастхэв.Ну так покажи то самое переименование/удаление файла силами сугубо make. Или что ты хотел сказать?
> Ну вот я такое считанные разы видел.
Судя по тому, что ты уже наплел про CMake, я уверен, ты вообще мало что видел.
> К тому что твой ExternalProject_Add() мало чем отличется от того если бы автор положил шелл скрипт который бы в начале собрал все зависимости их родными сборочными системами а потом дёрнул cmake собрать основной проект.
Он отличается всем. Во-первых, тут нет никаких шелл-скриптов, о которых ты упроямо вещаешь, во-вторых, работает на всех платформах, в-третьих, интегрируется в CMake.
Забавляет твое переобувание с "все скатывается к шел-скриптам" до "как если бы да кабы". В следующий раз лучше не умничай на темы, в которых не шаришь.
> Или что ты хотел сказать?У меня в системе rm и всё остальное есть а coreutils нет.
> Судя по тому, что ты уже наплел про CMake, я уверен, ты вообще мало что видел.нудануда.
> Во-первых, тут нет никаких шелл-скриптов, о которых ты упроямо вещаешь, во-вторых, работает на всех платформах, в-третьих, интегрируется в CMake.Я говорил другое: если дочерний проект не cmake то его подключение будет мало чем отличатся от вызова сборки шелл скриптом.
В остальном.
Я пока пользуюсь CMake у себя в проектах, но он мне не очень нравится: слишком много зависимостей он требует, включая тот же meson.
Месон мне не нравится и синтаксисом и упоростью в плане что нет возможности повлиять на подключение библиотек после pkgconfig.
Я бы предпочёл сборочную систему на LUA, как самый реально переносимый и кроссплатформенный вариант, с двумя зависимостями: рабочим шеллом и С компелятором.
> Кроме Make ничего не нужно.
> Почему? Да потому что все эти хипстерские билд стстемы тупо не умеют фиксить зависимости. Make тоже не может, но мейк это стандарт.Это не задача make. Проблема make в том, что он очень обобщен и для выполнения преобразования нужно вызывать внешнюю команду, что может быть долго.
> Это не задача make.Мне нжуно нажать и получить результат, а задача не задача это уже вопрос к автору. Почему он придумал гору абстракций.
Аналог pixi например берет выкачивает зависимость и ставит. Чем не замена make.
А muon успевает за релизами meson? Или как там вообще дела обстоят?
https://muon.build/releases/v0.4.0/docs/status.html
А на кой ему успевать? Его основная цель быть автономным (работать без Python)
с этой задачей он справляется. Другое дело, что его аудитория это эмбед,
а для этого нужно заовзить тулчейны для процессоров разных и разводить
кроскомпиляцию, а тут куча деталей с сотней параметраов.
> А на кой ему успевать? Его основная цель быть автономным (работать без
> Python)
> с этой задачей он справляется.Если заявляется как альтернативная реализация, то интерефейсу следует соответствовать. Какая разница без чего он там рабоатет, если проект, собирающийся на meson, на нем не будет собираться?