[d-kernel] kernel-headers-modules

[Ed V. Bartosh]

Hello,

 >> > /usr/include/linux-%version-%flavour? 
 >> Нужно поднять тред на эту тему, но, скорее всего, это было сделано для
 >> того, чтобы отделить это от  /usr/include/linux..., которые
 >> используются юзерспейсом. Не по ошибке точно.

 SV> Они будут отделены, так как юзерспейс полезет исключительно в
 SV> подкаталог include.

 SV> Если убирать - тогда и .config оттуда надо убирать.
А его вообще кто-нибудь там ищет ? Ему самое место в /boot, где он,
собственно говоря, и лежит.

 >> > В результате нет возможности
 >> > указать /usr/include/linux-%version-%flavour в качестве каталога с
 >> > ядром, если собираемому модулю нужны заголовки SCSI.
 >> Да, но никто не мешает указать оба места.

 SV> Речь о том, что некоторые вещи хотят именно каталог ядра, а include/
 SV> и drivers/scsi/ добавляют сами - понятно, что это решается либо
 SV> подстановкой значений для других переменных, либо патчем для
 SV> Makefile, но зачастую это только лишняя работа.
Согласен. Но с другой стороны указывать каталог, лежащий в
/usr/include в качестве SRCDIR - это тоже, кхм, попахивает чем-то
нехорошим :)

 SV> Можно пойти другим путём - сделать в
 SV> /usr/src/linux-%version-%flavour симлинк include ->
 SV> ../../include/linux-%version-%flavour/include; тогда заменителем
 SV> каталога с ядром будет выступать /usr/src/linux-%version-%flavour.
Может так оно и лучше будет. Нужно подумать.

 SV> Здесь проблема ещё в одном месте: при тестовых сборках скриптами в
 SV> CVS переопределяется %_usrsrc, из-за чего либо не находятся
 SV> исходники, либо эти файлы пишутся не туда, куда надо.  Можно это
 SV> обойти, но тогда в спеках придётся писать что-то вроде
 SV> %_includedir/../src/linux-%kversion-%kflavour/drivers/scsi.  А
 SV> ломать этот механизм сборки я не хочу, поскольку hasher пока что не
 SV> умеет работать с ccache.
А это не проблемы hasher-а или твоих скриптов ?

 >> > У меня ещё возникают мысли втащить в kernel-headers-modules файлы
 >> > Makefile, Rules.make и arch/i386/Makefile (слегка их попатчив, чтобы
 >> > ничего в дереве ядра не пересобиралось).  Некоторые модули хотят
 >> > собираться именно таким образом - не хочется это ломать (при сборке
 >> > таким методом получаются наиболее правильные опции gcc).
 >> Ну и какие же это include будут ? Вот поэтому и вынесено в том числе.

 SV> include для make (по крайней мере, Rules.make именно так и
 SV> используется).

 >> Я за то, чтобы добавить. Просто пока не нужно было, а в целом я - за.
 SV> Например, нужно для сборки bttv отдельно от ядра (тогда даже
 SV> Makefile патчить не приходится).
Да, у меня тоже уже примеров поднакопилось :)

-- 
Best regards,
Ed V. Bartosh