This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Request For Enhancement: crosstool support of arm (rmk only?) kernel patches


On Sun, Jan 25, 2004 at 10:42:53PM -0800, Dan Kegel wrote:
> I'm now supporting them in the following trivial way: if you want to
> use them, you can, by copying them into the right subdirectory of
> crosstool-0.27/patches.
> 
> ptxdist has the concept of a local patches directory already; why not
> just have the user unpack the patches he wants into that directory?  I
> guess the reason is that ptxdist likes to download its patches at
> build time.

Well, what I want to have for the "feature patches" like RTAI, KURT,
some strange kernel subsystems not in mainline yet etc. is that I have a
switch in the menuconfig frontend where I can enable/disable them for
certain scenarios. At the moment Marc has added a truely magic macro
which computes the name of the patch files from the names of the config
variables, whereas I would like to see a method which is easier
understandleble by muggles :-) 

There also is the requirement that, where we had things like -rmk trees
for ARM yet, the future will probably bring us something like adding a
set of let's say ~20 independend patches instead of one monolithic
architecture patch. This is already the case for our PPC trees and I'm
working towards such a solution also for the ARM boards as it is easier
to maintain. 

> (That's one thing I like better about crosstool than ptxdist:
> crosstool comes with the patch repository bundled in. IMHO this is a
> good idea because it makes the build less dependent on having a
> network connection, and it makes the build more reproducible -- you
> aren't at the mercy of the patch repository operator to quite the same
> degree.)

Well, that's a design feature not a bug ;) I see PTXdist not as an end
user tool, at least not in the way it falls out of it's tarball. Whe I
make a project for a customer which uses PTXdist to "executably
document" how the toolchain, kernel and userland are built I normally
use PTXdist as _my_ development tool, then qualify a set of options
which are needed for the customer and in the end burn the complete tree,
including original source files and patches on a CD which is shipped.
This is what the user works with, and he is also not dependend on his
network connection then any more. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstraße 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]