С мезоном нас!

Они говорят, что проще ninja под нужную платформу собрать (она простая, как валенок), чем писать генератор ещё и под make. Он ещё и тормоз. Короче, профита не особо, только геморрой.

Очередная генерилка для генерилки генерилки.

Очередная поделка, дублирующая смаку, только с синтаксическим питоносахарком.

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

Qbs рвет все эти мезоны и смаки в плане юзабилити и простоты.

Тем более в Qbs уже скоро должна появиться замена QtScript и можно ядро переписать на чистом STL, и выкинуть Qt (хотя наврятли, т.к. Qt уж очень удобен).

Я хз зачем мезон вообще нужен, какие преимущества дает, по сравнении с тем же Смаке.

Да и у нинзи проблема с ограничением на длину пути в 260 символов. Баг до сих пор на нинзевском баг трекере висит.

Кушайте, дрозофиллы, кушайте, пока не остыло, вам еще подольют добавки. )))

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

Хм

NYoH=['Conan', 'VcPkg']
NYoH.append('tup')

Универсальный генератор зависимостей для make на каком-нибудь awk быстрый будет?

Тем более в Qbs уже скоро должна появиться замена QtScript

Давно за ним не слежу. Последее, что о нем слышал - что он сам себя без cmake/qmake собрать не мог, т.к. зависил от кутей.

Уже починили?

пошел переписывать свои Cmake портянки

meson не замена cmake.

Cmake - система для сборки проектов любой сложности, а вот в meson широко применяются специальные костыли для конкретных библиотек вроде boost или gnome, или рекомендуют запускать внешние скрипты. На чем писать эти скрипты, если например проект надо собирать и под линуксом и под виндой, тактично не сообщается.

Имелось ввиду, что сам make куда медленней ninja. При том, что ninja довольно простая и собрать её под платформу, в общем, не сложно.

Вообще, как я понял подход, они сделали генераторы для компиляции на целевых платформах (если брать С/С++, то: ninja под Linux, msvc под Винду (впрочем, ничего не мешает юзать туже нинзю со студией или с clang, пробовал - работает), xcode под Мак) и на этом в принципе довольны. Делать отдельный генератор ещё и make - тонна работы, которую в проекте никто делать не хочет. Нет, если кто-то сделает, не ломая логику работы, то, скорей всего, возьмут с удовольствием, но вот прямо отдельно этим заморачиваться смысла не просматривается. Вот в FAQ, написано

А так, вон та же интеграция с CMake, насколько я понял, вообще проект отдельного товарища. И ничего, приняли, вполне дружит с проектами CMake и нормально работает. Кроме install targets или каких-нибудь лютых извратов, сабпроджекты собираются без правки (ну или минимальной правки) CMakeLists.txt . Потом и зависимости стало можно разрешать через cmake, и вообще meson тесно «дружит» c cmake и не стремится его вытеснять. Что логично, потому что в проекте, я так понял, прекрасно понимают, что все разом не метнутся переписывать всё на сабж.

На чем писать эти скрипты, если например проект надо собирать и под линуксом и под виндой, тактично не сообщается.

На python. Сам же meson на нём, следовательно, как-минимум python в системе должен быть.

Ну или shell и любые виндовые скрипты, как custom/run targets. Также как и cmake, в общем-то.

Автоматический конвертер любого языка программирования в Rust

ninja слишком низкоуровневая, никому неохота с ней напрямую возиться. Генерацию make делать вряд ли будут - он работает медленнее, а что meson, что ninja зависят от python.

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

Scons внутри своих файлов проекта позволяет напрямую на python писать.

Давно за ним не слежу. Последее, что о нем слышал - что он сам себя без cmake/qmake собрать не мог, т.к. зависил от кутей.

Блджд, это что, большая проблема что ли? Зачем тебе нужно чтобы Qbs бутстрапил сам себя?

Так scons изначально и задумывался так, насколько я понял. А в сабже python просто потому что писать быстрей (только из-за «батареек», в общем-то), да и есть везде, кроме особо упоротых товарищей.

meson широко применяются специальные костыли для конкретных библиотек вроде boost или gnome

Кстати, не понял, это о чём вообще? Про модули, чтоли? Конкретно про gnome - это обвязки над всякими гномьими gen-marshal,mkenums и прочими тулзами, вроде gir-scanner. Какбы логично это всё вынести в отдельный модуль и включать по необходимости.

Какие костыли применяются для boost?

В примерах вижу вот это:

boost_dep = dependency('boost')
exe = executable('myprog', 'file.cc', dependencies : boost_dep)

ну вот выше кидали ссылку на реализацию meson на сишке. Ninja тоже есть на сишке, samurai называется https://github.com/michaelforney/samurai

то есть по факту, если например пилишь контейнер для сборки какого-нибудь sway, то python там вообще не нужен. А если все-таки нужен, то к размеру контейнера легко может прибавиться метров 100. Неприятно.

Виндовые скрипты - тоже головная боль. Мощная щель есть не всегда, а батники - ужас на крыльях ночи.

В то же время в cmake все интересное мне можно реализовать средствами самого cmake.

модули, да. Может и логично, но топикстартер тут ругается, что на cmake портянки. Ну а модуль для gnome с 2200 строк кода - это разве не портянка? По-моему она самая

Я не ругался на портянки, это была ирония.

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

Ну вот почему-то тоже так кажется.

А что смущает? Скорее всего dependency() вызывает pkg-config и тащит информацию из него.

Так это ж не для конечного пользователя. Доступных для использования там всего 12 функций (описание модуля). Я как-то переписывал с тулзов на meson парочку штук на GTK: довольно удобно этим модулем пользоваться, на самом деле.

Про портянки: cmake действительно довольно многословный.

Меня ничего, а вот комментатора выше порвало.

Для меня - нет. Просто поинтересовался.