Re: Avoiding make-kpkg clean, redux

["Paul Smith" <psmith@nortel.com>]

%% "Roberto C. Sanchez" <roberto@familiasanchez.net> 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 <psmith@nortel.com>           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.