Gentoo и ccache

И?

Энтер 2 раза нажал при заполнении тэгов темы и она отправилась :(

Собственно в /etc/portage/make.conf есть такие настройки:

...
FEATURES="preserve-libs sign"
CCACHE_DIR="/var/tmp/ccache"
CCACHE_SIZE="2G"

# ls -l /var/tmp/ccache
total 4
-rw-rw-r-- 1 root portage 359 Oct 12 22:35 ccache.conf

 
#Overwrite default cache_dir
cache_dir="/var/tmp/ccache"

# Maximum cache size to maintain
max_size = 2G

# Allow others to run 'ebuild' and share the cache.
umask = 002

# Preserve cache across GCC rebuilds and
# introspect GCC changes through GCC wrapper.
compiler_check = %compiler% -v

# I expect 1.5M files. 300 files per directory.
cache_dir_levels = 3

FEATURES="${FEATURES} ccache"

категория/имя_пакета portage_ccache.conf

Может в make.conf надо так? Но это не точно FEATURES="${FEATURES} трололо"

Если я пропишу фичу cсache напрямую в make.conf, то он будет использоваться для всех пакетов, а это не то, что нужно. Так как он нужен мне именно для тестирования сборки определённых пакетов.

Но даже если пропишу туда, то всё равно ошибка будет той же самой. Уже как-то проверял в начале года.

К тому же, раз он всё-таки пытается что-то распихивать, то переменную окружения FEATURES он для пакета всё же перезаписывает.

пытается создать /root/.ccache

# /etc/portage/bashrc:
HOME="/var/tmp/portage/sandbox_home"

Баги по поводу env искать лень, их много.

Я не ccache имел ввиду. Его не надо в make.conf У вас FEATURES="preserve-libs sign" заменяет дефолтные портяжные. Имел в виду FEATURES="${FEATURES} preserve-libs sign"

portageq envvar CCACHE_DIR?

Зачем глобально если он его уже вынес в env для конкретного пакета?

Да, в make.conf у меня FEATURES=«preserve-libs sign» , a в env FEATURES=«${FEATURES} ccache» - так как что-то он куда-то связанное с ccaсhe пытается писать, то значит, фича вроде как подхватывается. Но это неважно - сайчас закомментировал в env для пакета и прописал в make.conf - та же самая ошибка.

хрень какая-то

# portageq envvar CCACHE_DIR
/var/tmp/ccache

# cat /etc/portage/make.conf | grep -i ccache
FEATURES="preserve-libs sign ccache"
CCACHE_DIR="/var/tmp/ccache"
CCACHE_SIZE="2G"

У тебя бардак с bashrc, env, package.env и где там еще можно переменные окружения прописать.

Хватит уже редактировать сообщения. Весь смысл диалога теряется.

извини, в команду случайно ? скопировал и она, естественно, ничего не выдала, в отличии от правильного ввода

никому не нужен твой $HOME/.bashrc
смотри в:

/etc/portage/bashrc
/etc/portage/env/*
/etc/portage/package.env/*

Добавлю. Все переменные окружения можно посмотреть в /var/tmp/portage/$CATEGORY/$P/temp/environment

/etc/portage/bashrc
/etc/portage/env/*
/etc/portage/package.env/*

у меня там нет никаких bashrc

что все таки показывает portageq envvar CCACHE_DIR

показывает /var/tmp/ccache

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

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

кривой ebuild, возможно, с кривой защитой от сборки с ccache

Уже посмотрел, там никаких странностей и в image нормально всё скидывается, а вот сразу после src_install() - нужно бы его отдельно запустить - он почему-то лезет куда-то не туда. И именно для разрабатываемого пакета - сам ccache c другим сработал нормально.

И вообще очень странно, что он вылезает из песочницы и пишет в /root/.ccache

Ну пока да, кривоват пока - там префикс ещё используются, может в них дело. Переработаю чуть по рекомендациям и ещё раз проверю, может сама система сборки scons не очень с ccache дружит

src_install() - нужно бы его отдельно запустить - он почему-то лезет куда-то не туда

Не надо дергать ccache в src_install. У тебя бардак в ebuild'е.

да не дёргаю я ccache в src_install - я думаю запустить src_install отдельно, чтобы понять на этом этапе хрень происходит или на следующей стадии, так как в image уже всё записано к этому моменту. В ebulild у меня никакого ccache нет, как и в SConstruct встроенное в scons кеширование не включено.

Может это связано с подобным багом: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299880

The reason is that scons (to «ensure» a consistent build environment) clears all environment variables.

Не дергай компилятор (в данном случае ccache) в src_install, даже через scons. Для этого есть src_compile (можно еще в src_configure).

Ничего я там не дёргаю в ebuild кроме scons build, scons install.
Ссache исключительно в make.conf прописан.

Баг старый, нужно в документацию углубиться, как это в scons работает и просто в ebuild тогда снова как-то переменные окружения для scons вставить. Хотя в баге пишут, чтов дебиане они (или вообще для ccache) это пофиксили.

В общем, я запутался и ничего не понял.
Не проще ли локализовать, где отваливается через последовательные ebuild $EBUILD unpack, configure, complie, install?

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

в ебилде используешь scons-utils.eclass?

да, без ccache всё собирается и ставится, даже внутренний тест проходит

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

залез в scons-utils.eclass

# Please note that SCons is more like a 'build system creation kit',
# and requires a lot of upstream customization to be used sanely.
# You will often need to request fixes upstream and/or patch the build
# system. In particular:
#
# 1. There are no 'standard' variables. To respect CC, CXX, CFLAGS,
# CXXFLAGS, CPPFLAGS, LDFLAGS, upstream needs to define appropriate
# variables explicitly. In some cases, upstreams respect envvars,
# in others you need to pass them as options.
#
# 2. SCons scrubs out environment by default and replaces it with some
# pre-defined values. To respect environment variables such as PATH,
# Upstreams need to explicitly get them from os.environ and copy them
# to the build environment.
#
# @EXAMPLE:
# @CODE
# PYTHON_COMPAT=( python2_7 )
# inherit python-any-r1 scons-utils toolchain-funcs
#
# EAPI=5
#
# src_configure() {
#       MYSCONS=(
#               CC="$(tc-getCC)"
#               ENABLE_NLS=$(usex nls)
#       )
# }
#
# src_compile() {
#       escons "${MYSCONS[@]}"
# }
#
# src_install() {
#       # note: this can be DESTDIR, INSTALL_ROOT, ... depending on package
#       escons "${MYSCONS[@]}" DESTDIR="${D}" install
# }

я подобные вещи использовал для пары вещей с помощью toolchain-funcs, но это было полгода назад, поэтому уже забыл об этом

надо же было мне так повезти, что тестировать ccache полез на пакете со scons :)

помечу тему как решённую, но если всё-таки получится туда передать параметры для ccache (не встроенный в scons), то отпишусь

Может быть поможет
http://wikigentoo.ksiezyc.pl/HOWTO_use_ccache_and_distcc_with_scons_build_too...

Спасибо. Полезная статья, хоть и не совсем помогла.

Наконец вернулся к этому вопросу. Начиная с ревизии dev-util/scons-3.0.1-r1 добавлен патч, который передаёт в scons все переменные окружения portage вместо их затирания. Это было сделано его ментейнером, чтобы в каждом пакете, зависящем от scons, каждый раз не городить соответствующие патчи.

Помимо этого, в файле SConstruct рассматриваемого пакета была строчка env = Environmet(... ENV={'PATH': os.environ['PATH']}, ...). После замены этого фрагмента на env = Environmet(... ENV=os.environ, ...) переменная окружения CCACHE_DIR из portage успешно передаётся в scons в начале его запуска, а не в другом месте скрипта SConstruct, где это было предусмотрено для других целей.

А так как данное исправление в моём случае вызывало ошибки с нахождением файлов во время внутренних тестов, то в итоге исправление было таким ENV={'PATH': os.environ\['PATH'\], 'CCACHE_DIR': os.environ.get('CCACHE_DIR','')}, чтобы всё корректно обрабатывалось и для FEATURES="-ccache".

Так как новость о самом приложении уже в архиве, то отпишусь здесь о новом пакете, ради которого эта тема была создана:
https://packages.gentoo.org/packages/sci-libs/cantera

Плюс оффлайн документация:
https://packages.gentoo.org/packages/app-doc/cantera-docs