LINUX.ORG.RU

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

 ,


0

3

6 марта состоялся выпуск системы сборки Scons 4.5.0. Вслед за ним было выпущено корректирующее обновление 4.5.1.

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

Помимо исправлений ошибок и небольших улучшений к основным изменениям в версии 4.5.0 относятся:

Новые возможности

  • Добавлен новый метод ValidateOptions(), который будет проверять, что все опции командной строки являются параметрами SCons или добавлены с помощью метода AddOption() в файлы SConstruct/SConscript. Эти параметры командной строки не должны вызываться до завершения всех вызовов метода AddOption().

  • Добавлена экспериментальная опция --experimental=tm_v2, которая активирует новую реализацию распараллеливания задач от Эндрю Морроу (Andrew Morrow). Опция также может быть активирована с помощью метода SetOption().

  • Добавлен параметр FILE_ENCODING, с помощью которого можно явно указать кодировку текста для файлов, записанных с помощью правил сборки Textfile() и Substfile(). Если параметр не задан, то по умолчанию указанные правила сборки записывают файлы в кодировке UTF-8.

Изменения/улучшения существующих возможностей

  • Добавлен поддержка опции -fsanitize для метода ParseFlags(). Её действие распространяется на переменные CCFLAGS и LINKFLAGS.

  • Вызовы методов EnsureSConsVersion() и EnsurePythonVersion() больше не инициализируют окружение по умолчанию, т.е. DefaultEnvironment.

  • Вывод в терминал метода Chmod() теперь отображается в восьмеричном формате, используя синтаксис современного языка Python (0o755 вместо 0755).

  • Проведена миграция реализации ведения логов для опции --taskmastertrace на использование встроенного модуля ведения логов языка Python. Добавлено ведение логов для новой реализации распараллеливания задач от Эндрю Морроу (Andrew Morrow).

  • Добавлена предварительная поддержка языка Python 3.12.

  • Вызов команды сборки LaTeX теперь происходит только после выполнения вызовов biber/bibtex, если это необходимо.

  • Конфигурация контекстных методов CheckLib и CheckLibWithHeader теперь расширена добавлением двух дополнительных аргументов: append, который управляет добавлением в конец списка (по умолчанию) или в начало списка $LIBS обнаруженных библиотек; и unique, который определяет добавлять ли библиотеку в список $LIBS, если она уже представлена в нём. Это изменение привносит дополнительную возможность управления списком библиотек с помощью обычных методов Append, AppendUnique, Prepend, PrependUnique.

  • Значения переменной CPPDEFINES, добавленные с использованием типа данных «словарь», больше не сортируются по значению ключа. Раньше сортировка использовалась, чтобы обеспечить сохранение порядка параметров командной строки при последовательных запусках SCons, но это приводило к тому, что макросы не всегда вызывались в том порядке, в котором были переданы. Улучшения интерпретатора языка Python больше не требуют использования сортировки. Может происходить однокаратная переборка целей, которые использовали отсортированные ключи в рамках своих вызовов.

Корректирующий выпуск SCons 4.5.1 исправляет следующую ошибку:

  • В определённых случаях после вызова метода Clone(), новое окружение разделяет переменную CPPDEFINES с исходным окружением Environment(), которое было скопировано. Значения этих переменных в данных окружениях должны быть независимы.

С полным списком изменений и исправлений ошибок в версии 4.5.0 можно ознакомиться по ссылке.

Изменения версии 4.5.1 приведены здесь.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: grem (всего исправлений: 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.

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

apt_install_lrzsz ★★★
()
Ответ на: комментарий от apt_install_lrzsz

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

grem ★★★★★
() автор топика

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

xwicked ★★☆
()

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

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

Bass ★★★★★
()
Ответ на: комментарий от DrBrown

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

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

grem ★★★★★
() автор топика
Ответ на: комментарий от xwicked

не могу 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, то не подскажу.

hobbit ★★★★★
()
Ответ на: комментарий от Meyer

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

hobbit ★★★★★
()
Ответ на: комментарий от X512

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

grem ★★★★★
() автор топика
Ответ на: комментарий от X512

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

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

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

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

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

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

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

grem ★★★★★
() автор топика

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

slovazap ★★★★★
()
Ответ на: комментарий от X512

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

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

dataman ★★★★
()
Ответ на: комментарий от slovazap

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

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

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

grem ★★★★★
() автор топика
Ответ на: комментарий от Bass

И какова скорость сборки в сравнении с 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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

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

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

grem ★★★★★
() автор топика
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

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

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

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

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

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

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

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

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

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

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

X512 ★★★★★
()
Ответ на: комментарий от Dr64h

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

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

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

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

Dr64h ★★
()
Ответ на: комментарий от Dr64h

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

Dr64h ★★
()
Ответ на: комментарий от grem

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

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

annulen ★★★★★
()
Ответ на: комментарий от Bass

Попытался ещё раз сравнить сборку 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 в памяти шла.

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

Подправленный 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
}
grem ★★★★★
() автор топика
Ответ на: комментарий от annulen

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

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

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

WatchCat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.