%% "Roberto C. Sanchez" <[EMAIL PROTECTED]> writes: rcs> I'm sorry, but this is wrong, as I have I done it. As long as rcs> your invocation of make-kpkg uses the same append-to-version as rcs> the previous invocation, then it will work. You may be rcs> experiencing trouble becuase you are trying to change it and rcs> subsequently confusing the kernel Makefiles.
Sorry, but this is not true. I just did it this morning. I ran make menuconfig and changed the ext3 filesystem from a loadable module to kernel embedded (from "M" to "Y"), and nothing else. I saved my config. (This is Linux 2.6.9, from kernel.org). I re-ran make-kpkg, and I did NOT change the version. In fact, I used my bash history to re-run the identical command. There was no output related to recompiling anything, so I got suspicious and I looked in the source tree, and sure enough the only ext3 object files were the .ko and the .mod.o; no "normal" .o. I then used the standard "make" command, not "make-kpkg", without doing anything else in between (no changes to .config, etc.) and this time it rebuilt things correctly. It's pretty clear that make-kpkg did not attempt to run the kernel "make" command. >> Your example here is too simple: to use ccache you need to assign a >> value containing whitespace to the CC variable: CC="ccache gcc". >> MAKEFLAGS='CC=ccache\ cc' make-kpkg ... rcs> I'm sorry, but I fail to see how escaping whitespace, which is rcs> standard practice in basically every shell, is a `hack.' That rcs> simply doesn't make sense. You're not looking closely enough: it's not enough to escape the whitespace. If that's all it was, then all of these should work, too; I'm interested to see how many people can figure out what's _really_ going on here ;-). $ cat Makefile all: ; @$(CC) foo $ MAKEFLAGS="CC=echo BAR" make foo $ MAKEFLAGS=CC=ccache\ cc make foo $ MAKEFLAGS='CC="ccache cc"' make /bin/sh: -c: line 1: unexpected EOF while looking for matching `"' /bin/sh: -c: line 2: syntax error: unexpected end of file make: *** [all] Error 2 $ MAKEFLAGS="CC='echo BAR'" make -f /tmp/x2.mk /bin/sh: -c: line 1: unexpected EOF while looking for matching `'' /bin/sh: -c: line 2: syntax error: unexpected end of file make: *** [all] Error 2 Those last two are actually very big hints. They should all say this: $ MAKEFLAGS='CC=echo\ BAR' make BAR foo Trust me on this: I happen to know something about this subject ;-). This is NOT a simple case of quoting whitespace to the shell: this use of MAKEFLAGS is a hack. It relies on undocumented knowledge of GNU make internals, that could change with any release, to work. And, certainly, no one without a lot of knowledge about GNU make is ever going to figure this out in the first place... except maybe by just trying different kinds of quoting until something happens to work. rcs> Given that what you are doing is a fairly uncommon case, a corner rcs> case even, and that you have a solution, why all the fuss? Using ccache to compile the kernel is a "fairly uncommon, corner case"? I shouldn't think so. And here again, this solution is not very obvious (although at least this one is guaranteed by the GNU make documentation). You're not going to have an average person, even one who knows make syntax, come up with it on their own. It relies on a feature specific to GNU make, used in a fairly unusual way. In short, I have a solution to these problems because I happen to know a WHOLE LOT about how GNU make works. What I'd like is for make-kpkg to work "as expected", so that one doesn't have to have that level of knowledge to get it to DTRT. An apropos of nothing, I fail to see why people asking straightforward questions on this list always seem to get so much static about it. It's perfectly acceptable to say "gee you're right, that _would_ be nice!" There's no need for all this defensive "why the hell would anyone want THAT?" posture. We all love Debian but no one would claim it's perfect: we'll never get it there without acknowledging areas for improvement when they're pointed out. Yes I understand that ultimately they should be pointed out in a bug report, but maybe I'm odd: I prefer to check to make sure my bug reports are actually appropriate before I file them. Maybe there're ways to do these things I don't know about (in which case it should be a documentation bug instead ;-)). -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> HASMAT--HA Software Mthds & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ------------------------------------------------------------------------------- These are my opinions---Nortel Networks takes no responsibility for them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]