Выпуск системы сборки SCons 4.5.1

RELEASE 4.5.0 - Sun, 05 Mar 2023 14:08:29 -

RELEASE 4.5.1 - Mon, 06 Mar 2023 14:08:29

Оперативно.

Now env[‘CPPDEFINES’] will contain ‘c’ when it should not.

Чот я суть этой записи не понял.

Это комментарий к примеру кода, где ошибка проявлялась в версии 4.5.0. Склонировали оуружение env в env1. После в CPPDEFINES от env1 добавили ‘c’, но это значение также добавилось и в CCPPDEFINES исходного окружения env, но оно не должно было добавляться.

Мне бы научиться пользоваться подобными штуками, а я не могу Makefile правильно настроить, чтобы у меня файлы переводы в Qt генерировались при сборке, а не вручную...

А что не получается?

хорошая билд система, только IDE ее не поддерживают

Товарищи, а расскажите — как оно в сравнении с CMake?

И какова скорость сборки в сравнении с CMake+Ninja?

Можно через compilation database — CLion, VSCode, Eclipse CDT и Qt Creator должны открыть.

Кто-то ей вообще пользуется?

Да, например Godot

Mongodb, Cantera, Battle for Wesnoth

Зачем оно когда есть Meson? Многие проекты уже перешли с SCons на Meson.

Это какие? На Meson же с autotools перебирались.

Mesa3D например.

Зачем нужен Meson когда есть божественный Cmake?

Там ужасно кривой синтаксис и поведение. Нет унификации, каждый делает свой велосипед для прописывания зависимостей, путей установок и т.д.. CMake плохо дружит с pkg-config.

Они же до 2019 autotools использовали и на meson перебирались тогда.

Проект mesa3d перешёл на сборочную систему meson

Я бы добавил ужасную документацию cmake и их tutorials с кучей воды.

не могу Makefile правильно настроить, чтобы у меня файлы переводы в Qt генерировались при сборке, а не вручную

Если у тебя qmake, то это пишется не в Makefile, а в самом pro-файле. Мне на prog.org.ru посоветовали такой вариант:

tr.commands = lrelease $$_PRO_FILE_
QMAKE_EXTRA_TARGETS += tr
POST_TARGETDEPS += tr

И выше по тексту надо указать, где лежат исходники переводов, вот кусок моего проекта:

TRANSLATIONS += \
    ../translations/doublecontact_de.ts \
    ../translations/doublecontact_fr.ts \
    ../translations/doublecontact_nb_NO.ts \
    ../translations/doublecontact_nl.ts \
    ../translations/doublecontact_pl.ts \
...

Если для cmake, то не подскажу.

Клиент SecondLife пользовался, когда я его тыкал.

https://gitlab.freedesktop.org/mesa/mesa/-/commit/6e6cd7d93cc54fc8c279377c2d552761f4457174

Это отказ от сопровождения ещё одной системы сборки. Некоторые проекты поддерживают скрипты для нескольких систем. Иногда даже больше 2 одновременно. Но это слишком затратно.

Короче был там когда-то SCons, а теперь нет. Теперь только Meson.

Ну и ладно, он там никогда основным не был. Его изначально добавили в 2008 году как альтернативную систему сборки. Что то на python, что это.

А вот Meson смог стать основным и наконец выкинул убогие автотулзы.

Что то на python, что это.

У языка Meson есть альтернативная реализация Muon на C99. Так что Питон не обязателен (хотя конкретно в Mesa Python ещё используется для кодогенерации, а не только для сборки).

О, класс, спасибо за инфу.

Ага есть muon, есть samurai (вместо ninja), но кто ими пользуется?

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

Muon позволяет осуществлять бутстраппинг ещё проще чем у Autotools. Для Muon не требуются Make, M4, Bash, Perl и Python.

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

Как мантейнер пакетов могу сказать что система сборки кошмарная. К счастью, я давно её не встречал in the wild - все свалили на кошерный cmake. Из того что помню, главная её проблема - что она не система сборки, а фреймворк для написания систем сборки, по сути. Из-за этого каждый проект городил своё обнаружение зависимостей, свою обработку флагов (в каждом проекте флаги компилятора называются и передаются по-разному, например где-то CCFLAGS через окружение, где-то CFLAGS через аргументы), свои опции, для простых вещей требовалась простыня императивной питоньей лапши с чтением файлов, запуском процессов и прочей дребеденью, которую приходилось перепатчивать целиком. Никакой декларативности вообще, никакой автоматизации рутины. Ну и совсем дикие проблемы типа очистки окружения по умолчанию, из-за чего ломался, например, ccache, и в каждый Env() приходилось добавлять environ. Плюс python2 vs. python3 - так как скрипты не декларативное описание целей, а простыня питона, куда натыкано принтов в случайные места, и добавлять в них скобки - обычные дело.

есть альтернативная реализация Muon на C99

От которой мало толку. Попробуйте собрать util-linux.

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

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

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

И какова скорость сборки в сравнении с CMake+Ninja?

https://mesonbuild.com/Simple-comparison.html

Тут получается SCons медленнее всех, включая Autotools.

Вот ещё для случая с Chromium:

When we first started porting Chrome away from just Windows, we intended to use Scons to build Chrome on all our platforms. But early on in development I discovered that Scons, despite its admirable goals of correctness and ease of use, was quite slow — it could take 40 seconds from starting Scons before it decided to build some source. I don’t necessarily fault Scons; Chrome builds as one single enormous executable with something like 30,000 inputs (including the entirety of WebKit) to the build system.

https://neugierig.org/software/chromium/notes/2011/02/ninja.html

Сравнивал скорость сборки battle for wesnoth - было помедленнее чем на ninja(через cmake), может на минуту на фоне 14 минут общего времени. Но я не уверен, что точно те же параметры передал в обоих случаях. Может как уменьшиться, так и увеличиться разница.

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

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

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

Так это преимущество ninja. Я одну строчку не меняю - у меня сборка в рамках опакечивания с нуля идёт всегда.

Мне пока интереснее, откуда берётся аж «20% выигрыш» при генерации ninja.build средствами meson по сравнению с cmake после конфигурации.

Я одну строчку не меняю - у меня сборка в рамках опакечивания с нуля идёт всегда.

Опакечивание – это отдельная тема с другой спецификой по сравнению с разработкой. Если слишком часто возникает необходимось собирать пакеты от малых изменений исходников, то можно начать задуматься в целесообразности пакета. Может быть make/ninja install напрямую лучше справятся с задачей.

По сравнению с delphi проги на c++ так долго компилируются и линкуются, что некоторые часами пишут код, прежде чем просто запустить компиляцию. Зато в случае с delphi можно хоть после каждого блока сборку запускать.

проги на c++ так долго компилируются и линкуются, что некоторые часами пишут код, прежде чем просто запустить компиляцию

Это очень сильно зависит от стиля написания C++ кода. Если не перебарщивать с шаблонами, грамотно организовывать заголовки, не подключать лишнее, не использовать монстров вроде Boost, то собираться будет быстро.

https://mesonbuild.com/Simple-comparison.html

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

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

По сравнению с delphi проги на c++ так долго компилируются и линкуются, что некоторые часами пишут код, прежде чем просто запустить компиляцию. Зато в случае с delphi можно хоть после каждого блока сборку запускать.

Ninja+CCache почти полностью решают эту проблему.

Для больших проектов еще нужен хороший линкер, вроде mold

Ещё кто-то использует штуки по типу Icecream, DistCC, разного рода экспериментальные компиляторы...

По сравнению с delphi проги на c++ так долго компилируются и линкуются, что некоторые часами пишут код, прежде чем просто запустить компиляцию

Сдается мне, что причина другая: эти «некоторые» просто могут писать код часами, не компилируя каждую строчку, так как не программируют методом тыка

И это тоже ;)

Попытался ещё раз сравнить сборку Battle for Wesnoth модифицировав ebuild под использование scons, насколько быстро получилось переделать.

cmake+ninja:

cmake -C /var/tmp/portage/games-strategy/wesnoth-1.17.11/work/wesnoth-1.17.11_build/gentoo_common_config.cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_CAMPAIGN_SERVER=OFF -DENABLE_SERVER=OFF -Wno-dev -DENABLE_GAME=yes -DENABLE_DESKTOP_ENTRY=yes -DENABLE_NLS=yes -DENABLE_NOTIFICATIONS=yes -DENABLE_STRICT_COMPILATION=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/games-strategy/wesnoth-1.17.11/work/wesnoth-1.17.11_build/gentoo_toolchain.cmake /var/tmp/portage/games-strategy/wesnoth-1.17.11/work/wesnoth-1.17.11
...
ninja -v -j4 -l0

configure (~4 сек) + compile = ~ 13 мин 50 сек

scons:

scons -j4 wesnoth build=release cxxtool=x86_64-pc-linux-gnu-g++ extra_flags_release=-march=native -O2 -pipe ccache=False nls=True notifications=True strict=False wesnothd=False forum_user_handler=False prefix=/usr

configure (~40 сек) + compile = ~ 14 мин 30 сек

То есть время самой сборки не очень то отличается, но начальная конфигурация и проверка зависимостей для этого пакета в данном случае (sdl, разные пакеты boost) почему-то долгая. В распакованном виде архив игры ~770 Мб, каталог сборки ~180 Мб.

Это на AMD 955 X4 3.2 GHz, может скорость диска влияет на время конфигурации (он не шустрый и на SATA 2). Сборка в tmpfs в памяти шла.

Подправленный ebuild-файл был таким (wesnoth-1.17.11-r100.ebuild. Установка не проверялась, только сборка; USE-флаги по сути были фиксированы значениями USE="dbus nls -doc -dedicated -server"):

# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=8

PYTHON_COMPAT=( python3_{8..10} )

inherit python-any-r1 scons-utils toolchain-funcs flag-o-matic xdg

DESCRIPTION="Battle for Wesnoth - A fantasy turn-based strategy game"
HOMEPAGE="http://www.wesnoth.org
        https://github.com/wesnoth/wesnoth"
SRC_URI="mirror://sourceforge/${PN}/${P}.tar.bz2"

LICENSE="GPL-2"
SLOT="0"
# uneven minor versions are development versions
if [[ $(( $(ver_cut 2) % 2 )) == 0 ]] ; then
        KEYWORDS="~amd64 ~ppc ~ppc64 ~x86"
fi
IUSE="dbus dedicated doc nls server"

RDEPEND="
        acct-group/wesnoth
        acct-user/wesnoth
        dev-libs/boost:=[bzip2,context,icu,nls]
        >=media-libs/libsdl2-2.0.4:0[joystick,video,X]
        !dedicated? (
                dev-libs/glib:2
                dev-libs/openssl:0=
                >=media-libs/fontconfig-2.4.1
                >=media-libs/sdl2-image-2.0.0[jpeg,png]
                >=media-libs/sdl2-mixer-2.0.0[vorbis]
                media-libs/libvorbis
                >=x11-libs/pango-1.22.0
                >=x11-libs/cairo-1.10.0
                sys-libs/readline:0=
                dbus? ( sys-apps/dbus )
        )"
DEPEND="${RDEPEND}
        x11-libs/libX11
"
BDEPEND="
        sys-devel/gettext
        virtual/pkgconfig
"

src_prepare() {
        default

        # respect LINGUAS (bug #483316)
        if [[ ${LINGUAS+set} ]] ; then
                local lang langs=()
                for lang in $(cat po/LINGUAS) ; do
                        has ${lang} ${LINGUAS} && langs+=( ${lang} )
                done
                echo "${langs[@]}" > po/LINGUAS || die
        fi
}

src_configure() {
        filter-flags -ftracer -fomit-frame-pointer

        scons_vars=(
                build="release"
                cxxtool="$(tc-getCXX)"
                extra_flags_release="${CXXFLAGS}"
                ccache=False
                nls=True
                notifications=True
                strict=False
                wesnothd=False
                forum_user_handler=False
                prefix="/usr"
        )
}

src_compile() {
        escons wesnoth "${scons_vars[@]}"
}

src_install() {
        local DOCS=( README.md changelog.md )
        escons install
}

Для больших проектов еще нужен хороший линкер, вроде mold

Меня несколько настораживают их проприетарские замашки. Версию для MacOS уже сделали под несвободной лицензией.

Первое - да. Синтаксис ужасен. Со вторым пытаются бороться, но тяжелое наследие висит гирями на ногах. Насчёт pkg-config, с проблемами не сталкивался. В CMake соответствуй макрос вполне нормально работает.