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

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

А что, если нужно собрать билд-тайм тулзы? Или собрать apk, в который кладутся x86, arm и aarch64 бинари?

Симейковая вкусность. В CMake такие файлы еще можно чейнить, что бы например связывать vcpkg и mingw сидя на Linux.

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

vcpkg

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

Ну так ничего не мешает выполнить сборку одновременно с x86 и aarch64. Я сомневаюсь что meson вообще поддерживает компиляцию инструментов и их последующий запуск за один шаг.

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

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

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

В моём понимании компилятор (тот, что collect, а не cc1) должен иметь возможность указания машины, binfmt, sysroot, стартфайлов, модели данных (ilp32/lp64/llp64), манглинга и calling conversion. Увы, сейчас даже в clang большая часть пвраметров захардкожено, а в gcc и подвано и смысл тулчейн-файлов просто теряется - вместо него хватает указать /path/to/arch-platform-vendor-gcc. По идее тулчейн-файл должен был быть в компиляторе, а не системе сборки (раз уж мы вызываем collect, а не cc1+as+ld напрямую)

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

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

Это же именно CMake генерирует всякие конфиги, ограничить только компилятор недостаточно.

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

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

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

CC=«aarch64-unknown-linux-gcc --sysroot=/path/to/sysroot» WINDRES=... cmake /path/to/project
Ну да, в случае нескольких машин может иметь смыслю при условии что gcc собран с поддержкой sysroot и не пытается включить файлы из /usr/include (а он иногда норовит это сделать)

Именно по этому несмотря на наличие jit, qemu, не будучи точным потактовым эмулятором, не способен в адекватную произврдительность.

А кто лучше него? Да и джит они редко используют. Они же КВМ и запилили в ядро изначально.

glib в несвязанном с gnome/gtk проекте (опциональный gui на gtk не считается) - в принципе признак кромешного бардака в нём

Посоветуйте другую библиотеку с реализацией контейнеров (только не stl, ибо она плюсовая).

Ну вот в CMake висит условие:

if exists /usr/include/libsystemd.h {
  #define HAVE_SYSTEMD
}

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

Мировая практика, не?

Это вы разрабам силанга скажите, где уже давно –target изобрели, так как он любые архитектуры поддерживает одним бинарём. Но речь даже не об этом, а о том, что мезон тупо переходит в режим кросс-компиляции, и с хостовыми таргетами работать не будет. А хотя бы подвязать кросс-компиляцию к саб-прожекту - и то нельзя.

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

Ну спасибо, а установленный компилятор, перед этим, конфигуре аутоконфовский найдёт, правда же? И мезону подсунет нужный файлик. :) Вот только мезон сам должен уметь искать, что доступно из указанных альтернатив.

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

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

(вообще-то собирать можно, проинсталлить уже не даст)

Такое условие с абсолютным путём в принципе некорректно. Чинить его билдсистемой - лишние костыли
Если там что-то вроде have_include(libsystemd.h) то ок

недавно кто-то тут упоминал STC: https://github.com/stclib/STC сама не юзала, не могу сказать ничего насчёт эффективности. но судя по описанию это оно самое: контейнеры в сишечке, с99/c11.

Это вы разрабам силанга скажите, где уже давно –target изобрели, так как он любые архитектуры поддерживает одним бинарём.

Самое то для компиляции laba7.c

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

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

Подход с разными builddir намного проще для восприятия.

Ну спасибо, а установленный компилятор, перед этим, конфигуре аутоконфовский найдёт, правда же?

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

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

Выше опять же описал, сначала готовится окружение с такими инструментами, потом запускается финальная компиляция проекта. Слишком жирные запросы к meson по моему.

недавно кто-то тут упоминал STC:

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

Если там что-то вроде have_include(libsystemd.h) то ок

Да, я про встроенные средства поиска файлов.

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

Самое то для компиляции laba7.c

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

Не фатально, выше написал. Можно вторую builddir для x86 создать.

Да вы не поняли, при чём тут другой билддир? Вам айрон_баг уже давала пример, допустим, прошивку кросс-компилим, а тулзы для работы с ней - нативные. Ну казалось бы, ладно, я уж по саб-прожектам разнесу… Но нет, мезон сказал «нет».

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

Опять не понял… Так если мезон сам не может поискать, есть ли у нас i386-gcc, или, может, есть i686-gcc, или, может, x86_64-gcc -m32, то кто за него это сделать должен? Он тупо не умеет НИЧЕГО в области кросс-компиляции, кроме самого базового захардкоженного сетапа.

ну и да, классика жанра же, uthash: https://github.com/troydhanson/uthash

вот её я, емнип, даже в дистрибутивах видела. хотя тоже библиотечка мелкая и нет проблем её подключить модулем, она вообще header-only.

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

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

Что одного clang --target мало. Выше уже обсудили, нужно больше чем поддержка со стороны одного компилятора.

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

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

Опять не понял… Так если мезон сам не может поискать

Сам поискать есть ли кросскомпилятор??? А откуда он вообще знает что он у меня лежит в /opt и там их пару штук? Откуда ему знать под какую архитектуру я хочу собрать проект?

Выше опять же описал, сначала готовится окружение с такими инструментами, потом запускается финальная компиляция проекта.

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

Слишком жирные запросы к meson по моему.

Да в смысле? У них уже есть флажок native: <bool> пер-таргетный. Но, в режиме кросс-компиляции, он тупо не даст нативный таргет проинсталлить, например.

Ну или есть саб-прожекты. Кто мешал сделать так, чтобы cross-file мог к саб-прожекту цепляться? Это что, мега-требования? Да это на 2 минуты правок!

В смысле? Как в мезоне это сделать?

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

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

Ну или есть саб-прожекты. Кто мешал сделать так, чтобы cross-file мог к саб-прожекту цепляться?

А там в подпроект не может протечь какая нибудь переменная INT_SIZEOF? Если может, то понятно почему так НЕ сделали.

Что одного clang –target мало. Выше уже обсудили, нужно больше чем поддержка со стороны одного компилятора.

Ну да, ещё мезон должен уметь передать силангу нужный таргет… И всё? :)

Я прекрасно понимаю о чем ты, я и предложил сначала собрать инструменты под x86, поместив их в $MY_SYSROOT

Да как это сделать, как? 2 независимых прожекта вместо 1го?

Сам поискать есть ли кросскомпилятор??? А откуда он вообще знает что он у меня лежит в /opt и там их пару штук?

А для чего, по вашему, нужны всякие find_program() https://mesonbuild.com/Reference-manual_functions.html#find_program

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

ему знать под какую архитектуру я хочу собрать проект?

Ещё раз повторяю: «есть ли у нас i386-gcc, или, может, есть i686-gcc, или, может, x86_64-gcc -m32» - что тут непонятного? Это всё - вариации 1й архитектуры, а не разных.

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

Ну и кто, в здравом уме, будет, при переходе с автотулзов на мезон, делить проект на 2 части? Потом ещё объяснять всяким debuild & rpmbuild что это теперь вовсе не мезон, и собирать надо вот этим скриптом, а не как вы привыкли работать с мезоном! Да и вообще, репозитарий гита на 2 разбить, а то ведь непонятно, как параллельно разные meson.build держать в 1й репе? :)

А там в подпроект не может протечь какая нибудь переменная INT_SIZEOF? Если может, то понятно почему так НЕ сделали.

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

Ну да, ещё мезон должен уметь передать силангу нужный таргет… И всё? :)

Нет, читай выше.

Да как это сделать, как? 2 независимых прожекта вместо 1го?

Издеваешься? Создай Laba1, Laba2. Желательно на диск C:\, и диске D:\ что бы не появлялось дурных вопросов. После этого ты можешь собрать Laba1 как x86, а Laba2 как arm64.

Так почему в тулчейн-файле я не могу точно так же указать альтернативы?

Я не разработчик meson, мне лично все эти поиски никогда не нравились. Если ты используешь компиляторы из дистрибутива, то они должны написать toolchain файл для meson, и ты можешь их использовать без написания своего, передав --cross-file TARGET_ARCH.

Желательно на диск C:\, и диске D:\ что бы не появлялось дурных вопросов.

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

Ну и кто, в здравом уме, будет, при переходе с автотулзов на мезон, делить проект на 2 части?

Сейчас чем больше подрепозиториев в проекте, тем лучше. 2 части это мало, вот две сотни это уже солидно. Как пример проекта который частично перешел на meson я уже упомянул Xorg, https://gitlab.freedesktop.org/xorg/driver

Нет, читай выше.

Тебе так сложно ссылку дать на собственный комент?

Создай Laba1, Laba2.

Это идиотизм. Никто не будет делить существующий проект на 2, и потом ещё всем автобилдерным тулзам объяснять, что «meson.build - это глюк, пользуйтесь вот этим скриптом».

Я не разработчик meson, мне лично все эти поиски никогда не нравились.

Будто их нет в афтоконфе, или где-то ещё.

Если ты используешь компиляторы из дистрибутива,

А то какие же ещё? Мезон ведь не позволяет собрать кастомный компилятор! Нет, по тому, что компилятор он на этапе конфигурации пробирует. А конфигурить отдельно по саб-прожектам он, бедняга, не умеет. В результате, компилятор возможен только из дистрибутива.

то они должны написать toolchain файл для meson, и ты можешь их использовать без написания своего, передав –cross-file TARGET_ARCH.

А вы их не забыли в известность поставить, что они теперь должны вам для месона кросс-файлы делать? И силанг не класть. :)

Нет (поддержки в компиляторе недостаточно), читай выше.

Тебе так сложно ссылку дать на собственный комент?

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

Это идиотизм. Никто не будет делить существующий проект на 2, и потом ещё всем автобилдерным тулзам объяснять, что «meson.build - это глюк, пользуйтесь вот этим скриптом».

Я думаю на meson можно и верхний уровень автоматизировать, там же наверное есть аналог system() из С. Не считаю такой подход особо странным.

А то какие же ещё? Мезон ведь не позволяет собрать кастомный компилятор!

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

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

Этот комент сюда не особо-то и относится. Когда и где вы в последний раз видели компиляторы в виртуальном сисруте?

$ which i686-w64-mingw32-gcc
/usr/bin/i686-w64-mingw32-gcc

Да и в мезоне не сисрут указывается, а индивидуальные бинари.

Так ещё раз: мы силанг не поддерживаем в качестве кросс-компилятора?

Я думаю на meson можно и верхний уровень автоматизировать, там же наверное есть аналог system() из С. Не считаю такой подход особо странным.

Ну то есть, тебе не кажется странным колхозить саб-прожекты там, где они, номинально, и так уже есть, просто не работают? И, ради этого, переходить с другой системы сборки, где этого делать не требовалось - это тоже совсем не странно?

А то ты так захочешь и что бы тебе meson настраивал IDE скоро.

Я всего лишь хотел, чтобы у него нормально работали саб-прожекты, флажок native: <boolean> и альтернативы в файлах тулчейнов, а так же и силанг в качестве кросс-копилятора.

Это много?

Я думаю на meson можно и верхний уровень автоматизировать, там же наверное есть аналог system() из С. Не считаю такой подход особо странным.

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

Этот комент сюда не особо-то и относится. Когда и где вы в последний раз видели компиляторы в виртуальном сисруте?

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

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

я периодически собираю всё в чруте.

Но мезон тут не при чём, так как ему же не сисрут надо указывать, отдельные бинари.

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

Но мезон тут не при чём, так как ему же не сисрут надо указывать

Параметр sys_root

Параметр sys_root

https://mesonbuild.com/Cross-compilation.html#properties

The sys_root property may point to the root of the host system
path (the system that will run the compiled binaries). This is
used internally by Meson to set the PKG_CONFIG_SYSROOT_DIR
environment variable for pkg-config. If this is unset the host
system is assumed to share a root with the build system.

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

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

Ну да, все очень криво, он только для pkg-config: https://github.com/mesonbuild/meson/issues/13217

Я думал это аналог CMAKE_SYSROOT.

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

glib в несвязанном с gnome/gtk проекте (опциональный gui на gtk не считается) - в принципе признак кромешного бардака в нём

Qt зависит от glib из коробки.

Симейковая вкусность

https://c.tenor.com/-1rbTbNSLg0AAAAd/tenor.gif

После этого треда, только больше убедился в том насколько хорош CMake.

кста +много

Iron_Bug: уж если выпиливать то sh. оставлять ipython uv(увы) ну и cpython как зависимость для ipython

они даже не чешутся насчёт опенсорца.

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

Производя продукт сертифицируемый ФСБ посредством которого взаимодействуют не только с госуслугами или налоговой, но и с другими интересными организациями, внезапно оказаться крайним не очень хочется.

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

Еще раз, вкорячивать Магму и Кузнечика можно конечно и самому, но зачем?

И вообще, Родина дала мне браузер с ГОСТ шифрованием, флешку с бесплатной лицензий на Крипто Про обновляемой каждый год при генерации нового сертификата и возможность платить 0 рублей налогов. Кто я такой чтобы этим не пользоваться?