Re: [devel] re-writing GNU C; part1.4.1: .rpm produced

[Ivan Zakharyaschev <imz@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 5281 bytes --]

On Tue, 16 Feb 2016, Ivan Zakharyaschev wrote:

> Чтобы поскорее иметь возможность подсовывать cuglify/Process в hasher, стал 
> делать .rpm (дурацким временным способом).

Я думал ставить в hasher специальный пакет, чтобы заставлять при сборке 
использовать нечто другое вместо gcc (например, cuglify/Process, clang -- 
в общем, есть варианты, на чём проверить).

(Решил пока всё же в первую очередь доделкой фич в cuglify/Process
заняться. Поэтому записываю соображения про подмену gcc в hasher, чтобы 
не забыть/было что пока обсудить.)

При этом пакеты хотят для сборки gcc (иногда -- явно заданной версии).
Так пусть эти gcc ставятся.

Что-то похожее по смыслу происходит при использовании ccache и distcc:
стоит настоящий gcc, но вызовы gcc обрабатываются сначала этими
прослойками. (Между прочим, если пробовать это с clang, то gcc тоже
должен стоять, потому что, как известно, он ему нужен по зависимости.)

Вообще, вокруг gcc есть механизм alternatives для выбора варианта (и
/usr/sbin/select-gcc , который ими манипулирует).

Когда вчера рассуждал вслух в разговоре с mike@ о том, какая есть практика 
использования, к примеру, ccache вместо просто gcc в hasher, говорил, что 
странно, что не видно задокументированного надёжного прямолинейного 
способа сделать такую подмену, а, кажется, есть только какие-то 
rpm-макросы, которые по моему предположению меняли вызовы CC (если они 
соответствующе оформлены).

Вчера я почему-то упустил из виду, что gcc и cpp и компания у нас -- 
символические ссылки, ведущие на gcc_wrapper (а не альтернативы, 
предосталяемые разными gccN.M). Так что всё под контролем gcc_wrapper. А 
ведь я давно об этом знал.

$ readlink -f /usr/bin/gcc
/usr/bin/gcc_wrapper
$ readlink -f /usr/bin/cpp
/usr/bin/gcc_wrapper
$ rpm -q cpp5 -l | fgrep alter
/etc/alternatives/packages.d/cpp5
$ cat /etc/alternatives/packages.d/cpp5
/usr/bin/x86_64-alt-linux-cpp	/usr/bin/x86_64-alt-linux-cpp-5	511
/usr/share/man/man1/cpp.1.bz2	/usr/share/man/man1/cpp-5.1.bz2	/usr/bin/x86_64-alt-linux-cpp-5
$

Меня, навреное, вчера сбило то, что /usr/bin/gcc всё-таки тоже управляется 
альтернативами, и сейчас используемая альтернатива для него (gcc_wrapper)
предоставляется пакетом gcc-common:

$ l /usr/bin/gcc
lrwxrwxrwx 1 root root 36 дек 29  2014 /usr/bin/gcc -> /etc/alternatives/links/|usr|bin|gcc
$

Не знаю, есть ли в Сизифе другие пакеты, которые другую альтернативу для 
него дают.

(BTW, не смог найти команду, которая бы показывала бы, какие есть 
установленные в системе альтернативы для определённого пути. Например: 
хочу знать, какие есть альтернативы для /usr/bin/x86_64-alt-linux-gcc . 
Только grep-ать /etc/alternatives/?)

Какой-нибудь пакет dummy-gcc-clang или dummy-gcc-cuglify, который мы будем 
просить hasher установить в сборочную среду, мог бы как раз предоставлять 
альтернативу для /usr/bin/gcc (и /usr/bin/cpp) с очень большим 
приоритетом. Или задействовать существующий gcc_wrapper для того, что 
нам хочется (если в нём такое предусмотрено; и ещё бы как-нибудь 
запретить её переключать, если в gcc_wrapper есть такая возможность).
И можно было бы передвигать другие пути к GCC вроде /usr/bin/gcc-5 или 
/usr/bin/*-gcc , чтобы гарантировать, что к ним напрямую не обращаются во 
время сборки. (Напимер, файл-триггером, потому что я не уверен, что в 
hasher есть hook для выполнения команды после установки сборочной среды.)

-- 
Best regards,
Ivan