[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen Makefile being nasty with EXTRAVERSION
Ok, after writing this, I decided to add thisheader, warning mini-rant follows. ;-P Personally, I compile about 7 or 8 different kernels, with 3 different unfied diff patches and modules options to completely setup my cluster. SO, doing it inside make world, is a really ugly option. Hence writing xenlinuxbuilder. To be completely honest, I dislike the curent sparse patchfile setup with a passion. 8-P It's a RPITA to work with when packaging xen for Debian (or other distros that uses src tree patches for their main kernels) and for creating multiple kernels using different unified diff patch files for each kernel. I have to copy the linux source tree 4 times to get a clean patch of xen+distro patches as a unified diff since debian distributes kernel-source-* with their patches already in it (I'm certain other distros have their own patches as well) to keep from a: blowing up the debian source tree (this is partly debian's fault, sinc e it distributs a patched kernel source instead of pristine that's then patched to get debian's kernels). I understand why it's a sparse patch file, reduces bulk by quite a bit. But It's darn unfriendly when you want to compile both 2.4 and 2.6 kernels along with your distros patches. 8-P Not to to mention the fact that it walks ALL over any distro kernel src tree that's been patched since it replaces a few of the standard distro files outright. 8-P If you want any part of xenlinuxbuilder for the xen distro, feel free to grab it. It's GPLd (hell, I'll special license as bsd if necessary). Same thing with anythign in the debian packaging from debian/*. It's just another Makefile. The only real debian specific part is the tarball location for the kernel source and the xen_patch_ver check function. But please, for the love of my sanity and other distro's (besides redhat) can we take a really hard look at the patches beyond just the extraversion being a bummer? :) Like providing a tool with the xen tarball for creating the kernels? Or even a faster conversion of the sparse patchfile to a unified diff that can then be applied to separate kernel trees without linking back into the xen headers? (maybe a bit more inteligent in my debian packaging on how much of the kernel tree to unpack, patch, copy, diff, repeat...?) Symlinks of directories can be SUCH a PITA when patching after xen. As can the complete replacement of individual files. 8-P If not, i'll just continue to do the conversion at packaging time and smile nicely. :) Sometimes a package like xen is worth some extra steps to get it packaged fo ryour distro. Sorry for the rant, this was the largest part of packaging xen, getting the patchfile converted to a diff and playing nice with other patches without the end user having to think about sparse vs diff ordering and care. If i'm just being completely boneheaded here, just smack me and send me back to pascal 101. ;-P If i'm not being a bonehead, I'll start looking into a more inteligent method of converting things so it's faster and can be made a part of the xen dist files. Brian Wolfe On Sat, 2004-10-23 at 06:15, Ian Pratt wrote: > > > > Yeah, playing with the directory name is gross! > > > > I'm trying out replacing this with: > > XENVERSION ?= -xen > > EXTRAVERSION := $(EXTRAVERSION)$(XENVERSION) > > > > I've then changed the repository makefile to override XENVERSION with > > -xenU or -xen0 as appropriate. If it works as expected I'll check it > > in. > > That's going to be a pain to remember to set XENVERSION on the > command line if we're building directly within the kernel > directory, which people do all the time (e.g. after changing the > config on a kernel). I think 'baking' the extraversion into the > tree via a .extraversion file is the best soloution. > > Ian > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/xen-devel ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |