On Fri, May 27, 2005 at 04:57:33PM -0400, Paul Smith wrote: > %% "Roberto C. Sanchez" <roberto@familiasanchez.net> writes: > > >> What do I need to do to use make-kpkg to build my kernel packages, but > >> avoid having to run "make-kpkg clean" between every build? I'm > >> upgrading to a 2.6 kernel and I'm tweaking and poking at my config. > >> Running a build after a clean takes too long. Even with ccache. > > rcs> Add 'do_clean := NO' to /etc/kernel-pkg.conf. > > Ah! Another one from the previous thread. The discussion around this > was confusing to be sure, and Manoj generated a bit of it himself :-). > Contrary to what I understood him to say, if this variable (do_clean) is > set to YES then the kernel WILL be cleaned automatically after EVERY > invocation of "make-kpkg kernel_image". I verified this both by looking > at the man page (which is correct) and at the implementation itself. > > Obviously, this is bad. This is not exactly what I'm talking about > though: having this variable set to something other than YES is a > necessary, but not sufficient, step. > > In fact, if you go look at the actual content of the rules file you'll > see that the default value of this variable is actually _already_ NO (at > least in my versions of kernel-package -- 8.135). So, the above change > has exactly no effect. > > > Further, this is not really what I'm talking about. Assume that this is > done, and the kernel source is not cleaned up after the kernel_image. > > Now, I want to make a change to the configuration and rebuild. I can't > do this using make-kpkg, without either (a) knowing some undocumented > magic steps, or (b) running make-kpkg clean first. I don't want to do > option (b), so I'm asking someone to document (and, preferably, SUPPORT > so it's not magic anymore) option (a). I'm fine of the docs list it as > "for experts only", etc. I just don't want to have to learn the entire > implementation of make-kpkg to find out what it is. > > As I said, the simple-minded approach of just re-running make-kpkg > kernel_image without doing a make-kpkg clean DOES NOT WORK: it doesn't > invoke the kernel makefile at all (at least it didn't when I tried it). > There is more that must be done: some make-kpkg-generated stamp files or > something need to be removed, probably. But nowhere in the > kernel-package documentation (that I could find) does it tell you what > you need to do... and ideally there would be some target to make-kpkg > that would do it for you. > I'm sorry, but this is wrong, as I have I done it. As long as your invocation of make-kpkg uses the same append-to-version as the previous invocation, then it will work. You may be experiencing trouble becuase you are trying to change it and subsequently confusing the kernel Makefiles. Now, if you install a kernel with the same name over another one, dpkg will complain loudly. It will complian, but it will let you do it. > rcs> As far as using ccache, you are able to specify your C compiler on the > rcs> command line. From the make-kpkg(1) man page: > > rcs> You may control > rcs> which version of gcc used in kernel compilation by setting > rcs> the Makefile variables CC and HOSTCC in the top level > rcs> kernel Makefile. You can do this simply by > > rcs> % MAKEFLAGS="CC=gcc-2.95" make-kpkg ... > > rcs> (please see the top level kernel Makefile for variables > rcs> that can be set). > > Your example here is too simple: to use ccache you need to assign a > value containing whitespace to the CC variable: CC="ccache gcc". Doing > that via MAKEFLAGS is much more complex than the above example. > MAKEFLAGS is technically not designed for this type of argument passing: > MAKEFLAGS is really designed for parent makes to pass flags to > sub-makes. It's also available for users to set SIMPLE command line > options, like -k etc. in their environment if they want to. > > Using MAKEFLAGS like this is a hack and it's difficult to use correctly > with ccache, due to the quoting issues. You'd need to do something > like: > > MAKEFLAGS='CC=ccache\ cc' make-kpkg ... > I'm sorry, but I fail to see how escaping whitespace, which is standard practice in basically every shell, is a `hack.' That simply doesn't make sense. > And this relies on knowing some internal implementation details about > how GNU make works when it invokes recursive makes: it's not guaranteed > to work in future versions as it's undocumented. Finally, note that it > is probably much harder to do this in csh where quoting is very bizarre. > Of course csh sucks anyway but... > > Why can't we do something like: > > make-kpkg ... CC="ccache gcc" > > and have make-kpkg pass any argument which is a variable assignment down > to the kernel build system? That's simple enough. > Do an 'apt-get source kernel-package', patch it and file a bug with the patch attached to it. > > I actually did figure out a way around this; you can add this to your > ~/.kernel-pkg.conf file (or /etc/kernel-pkg.conf if you prefer): > > override CC = ccache $(CROSS_COMPILE)gcc > > By adding the "override" keyword this setting will take precedence over > the one that comes later, in the kernel's makefile. It will also > override any command-line settings, but as above make-kpkg doesn't allow > them anyway. But, if you wanted, you could do something like this: > > ifneq (command line,$(origin CC)) > override CC = ccache $(CROSS_COMPILE)gcc > endif > > Now, it won't override a command-line setting of CC. > > I'd still prefer make-kpkg to support this directly. > Given that what you are doing is a fairly uncommon case, a corner case even, and that you have a solution, why all the fuss? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr
Attachment:
pgpR_STTiicKb.pgp
Description: PGP signature