X.Org, ещё один проект отказывается от autotools

Наброшу: чем meson лучше scons? Оба на python.

За Meson имеется спина RedHat и куча Linux’овых проектов которые переведены на него. А SCons уже держится за крышку гроба.

Нужно тогда было сравнивать SCons и waf.

Секунды.

Вот скрипт генерации: https://raw.githubusercontent.com/wiki/jpakkane/meson/gen_src.py

Вот скрипт измерения: https://raw.githubusercontent.com/wiki/jpakkane/meson/measure.py

Напиши авторам meson, что их данные устарели, если ты думаешь что scons не в разы медленнее чем meson.

Так meson разве сам собирает? Разве он не занимается исключительно конфигурацией? Собирает ninja же, не?

За Meson имеется спина RedHat

Фу, как банально.

куча Linux’овых проектов которые переведены на него

При этом часть опций, присутствующих ранее в autotools куда-то девается (не полностью переводят что ли), что делает управление сборкой менее гибким.

SCons уже держится за крышку гроба

Тебе опять кошмары снятся?

Собирает ninja же, не?

Да, ninja.

Видимо генерируются разные ninja скрипты.

Я без понятия что делает Scons. Но CMake/Make, PreMake, Autotools тоже лишь генерируют Makefile, но время сборки у них также отличается, хотя собирает же make.

Фу, как банально.

Это как раз самая суть. Можно создать крутую систему сборки (QBS), но если она не найдёт отклик в IT-компаниях, она уйдёт в небытие. А можно создать какашку-говняшку (CMake) которую поддержит какой-нибудь Google и вот он, новый идиотский и неудобный стандарт в мире C/C++ разработки.

При этом часть опций, присутствующих ранее в autotools куда-то девается

Возможно, депрекейтится и выкидывается.

SCons уже держится за крышку гроба

Тебе опять кошмары снятся?

Количество собираемых SCons’ом в Linux таких базовых вещей как Mesa, X11, GTK+ и т. д. стремится к нулю, следовательно SCons в мире Linux распространён на уровне погрешности.

Вот скрипт измерения

Злой он :( пути к meson и premake захардкодил в своей домашней директории.

Хз как в scons работает эта экспериментальная фича, но разницы я не заметил в этом тесте.

Отличная документация? Где почитать про CMAKE_C_COMPILER_ARG1?

попробовал 2021.3 EAP.

Из наблюдений - main в тесте не определился, ща буду приседать в попытках его таки собрать-запустить-отдебажить. Плюс какая-то фигня с определением части стандартных хедеров, подозреваю яблочную боль (например не видит malloc.h при сборке но внезапно видит его в code completion). Есть собирать из консоли - все ок.

Проект и собственно тест: https://github.com/freeswitch/spandsp/blob/master/tests/fax_decode.c

Сразу скажу что мопед не мой и к его разработке отношения не имею

P.s. ну и конфиг я разумеется подправил чтоб оно вообще тесты в билд включило

Лень искать коммент, где-то тут было про мезон и питон.

Так вот пажалста: сегфолт — кросивое: https://github.com/pyenv/pyenv/issues/1889#issuecomment-833313816

Говорят, у вас, мол, слишком новый gcc, даугрейдьтесь.

Зашибись завязываться на такие сложные кодовые базы конечно.

У меня вот такая же фигня, кстати.

Там случайно не GCC виноват? У меня он не раз генерировал откровенно битый код.

Может быть, но мне от этого без разницы.

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

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

Безотносительно мезона, но мне потом еще питон-приложение под винду паковать.

Элементарно же. Посмотрите например на youtube-dl.

Спасибо. Посмотрю. Ни разу не сталкивался.

Где почитать про CMAKE_C_COMPILER_ARG1?

А вы с какой целью интересуетесь, свой toolchain пишете?

мне потом еще питон-приложение под винду паковать. Вот там я наверное наприключаюсь

Какая разница под что паковать? Не, если хочется прям полный фарш вместе с интерпретатором и dll - есть фриз. А так, особенно если сишных биндингов нет, setuptools это все прекрасно сам делает

Ну, у меня там куча либ в зависимостях, я еще не разбирался, что к чему. Под винду всё поставлялось в виде папочки с экзешником а ля «бери и запускай». Кодовая база мне только недавно досталась. Я по большей части её в докере пока гоняю.

Сам себе отвечу - гоню, под мак половина тестов не собирается. Но конкретно интересующий вроде как собирается

Под винду всё поставлялось в виде папочки с экзешником а ля «бери и запускай»

фриз. В 90% случаев проблем нет. В оставшихся 10% - бывают, особенно если гуй и Сишка

Я бегло посмотрел – проект несколько странный в том смысле, что:

1. тесты не включены по умолчанию (нужно явно вызывать path/to/configure --enable-tests) и, если их включить, то собираться они будут по make all а не по make check (в данном конкретном проекте цель check пустая, хотя обычно all собирает «боевой» код, а check – «боевой» и тестовый), и
2. тесты не собираются при включённой VPATH-сборке (это которая out-of-tree):

$ make all
Making all in src
Making all in spandsp-sim
make[1]: Entering directory '.../spandsp/build/spandsp-sim'
gcc -DHAVE_CONFIG_H -I. -I../../spandsp-sim -I../src  -I.. -I../src -DDATADIR="\"/usr/local/share/spandsp\"" -I/usr/include/libxml2 -DNDEBUG -msse2 -Wunused-but-set-variable -std=gnu99 -ffast-math -Wall -Wunused-variable -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fvisibility=hidden -DHAVE_VISIBILITY=1   -MT make_line_models.o -MD -MP -MF .deps/make_line_models.Tpo -c -o make_line_models.o ../../spandsp-sim/make_line_models.c
In file included from ../../spandsp-sim/make_line_models.c:55:
../src/spandsp.h:50:10: fatal error: spandsp/telephony.h: No such file or directory
 #include <spandsp/telephony.h>
          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:522: make_line_models.o] Error 1
make: *** [Makefile:509: all-recursive] Error 1

Т. е. я бы сказал, что авторы просто не осилили Autotools, даже на уровне базовых вещей.

С учётом вышесказанного, при открытии проекта в CLion надо:

1. отключить VPATH-сборку (этот режим включён по умолчанию) путём подстановки значения . (текущий каталог) в поле Build directory, а также
2. явно добавить --enable-tests к ключам сценария configure.

В результате настройки проекта будут выглядеть так.

После этого вызываем Tools -> Makefile -> Clean and Reload Makefile Project. Отныне каталоги tests/ и test-data/ будут обрабатываться корректно, а их содержимое станет частью проектной модели (не будет «красного» кода в окне редактора).

Далее, для того, чтобы запустить конкретный тест (напр, fax_decode), нужно создать конфигурацию (run configuration) типа Makefile Application, где в кач-ве цели Make указать check (нам нужно собрать тесты перед запуском), а в кач-ве исполняемого файла – путь к исполняемому файлу, как это показано на снимке. Имя конфигурации может быть произвольным.

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

я бы сказал, что авторы просто не осилили Autotools, даже на уровне базовых вещей

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

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

А вы с какой целью интересуетесь, свой toolchain пишете?

Я интересуюсь в пику заявлениям про «отличную документацию». На качество этой документации я насмотрелся, когда заводил сборки Tizen’а в Open Suse Build System.

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

https://www.phoronix.com/scan.php?page=news_item&px=Wayland-1.20-Alpha

Wayland 1.20 is also dropping its Autotools build system support completely in favor of Meson.

Ещё один гвоздь в крышку гроба Autotools

Для создания проекта документация у CMake хороша

Учитывая что каждый первый проект хардкодит путь от prefix до libdir, а каждый второй делает set(CMAKE_C_FLAGS "-O0 -ggdb") эффективно уничтожая возможность малой кровью при пакетировании докидать дистроспецифичные флаги вместо хотя бы set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -O0 -ggdb") не говоря уже про target_compile_options, то документация и для создания проекта не очень.

А учитывая что все эти target_compile_options добавляют флаги в конец и у того кто пакетирует софт в принципе нет инструмента, кроме патчей на CMakeLists.txt, для того чтобы хотя бы переопределить список включённых варнингов, то я не уверен что разработчики CMake’а хоть раз слышали про то как дистрибутивы собирают свои пакеты.

Косячат пользователи, а виноват CMake? В доках в нескольких местах написано – делайте относительные пути, но судя по вопросам на SO, доки никто не читает. А еще софтописатели крайне неохотно обновляют сборочные скрипты.

Конечно. В автотулзах у тебя с самыми косячными пользователями есть ./configure --libdir=/usr/lib64, а у симейкопользователей ты чуть менее чем наверняка найдёшь install(TARGETS mylib LIBRARY DESTINATION lib). Такие примеры и пользователи дают и книжки по симейку: https://cliutils.gitlab.io/modern-cmake/chapters/install/installing.html

А как тебе такое, Девид Блейн:

    # jam is weird, likes to error
    jam || true

И затем несобранная прога засовывается в пакет!