From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Comment-To: Sergey Vlasov To: ALT Linux kernel packages development Subject: Re: [d-kernel] kernel-headers-modules In-Reply-To: <20031006130020.GB1085@master.mivlgu.local> (Sergey Vlasov's message of "Mon, 6 Oct 2003 17:00:20 +0400") References: <20031005131706.GA18556@sirius.home> <20031006130020.GB1085@master.mivlgu.local> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Mon, 06 Oct 2003 16:41:07 +0400 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 13:43:12 -0000 Archived-At: List-Archive: List-Post: 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