Subject: Re: Slackware 8.1
From: Christopher E. Brown (cbrown@woods.net)
Date: Thu Jul 04 2002 - 00:49:18 AKDT
On Wed, 3 Jul 2002, James Gibson wrote:
>
> On Wed, 3 Jul 2002, James McMorris wrote:
> > > > make mrproper
> > > > make menuconfig
> > > > make dep
> > >
> > > > make clean
> > >
> > > I don't use this method myself but why 'make clean' ?
> >
> > >From the UNIX Handbook:
> >
> > When a "make clean" is executed, the "clean" section of the Makefile
> > will remove all the object files, executables and core files. This is
> > usually done to save space or right before a fresh compile.
> >
>
> Thanks for the link, quite useful... The more 'street-learned' reason to
> use 'make clean' is 'cause leaving previously compiled object files (*.o)
> can occasionally cause headaches, especially when you've changed
> configuration files or header files between builds.
>
> The whole makefile scheme is generally intelligent enough to recompile
> object files that are affected by configuration changes, but occasionally
> one or two slip through the cracks. These can be a bugger when they
> strike.
In this case 'make mrproper' does a total clean, including everything
'make clean' does. However, including the 'make clean' is a good
thing, as many times you do not do a make mrproper first (ie are just
making a change to an existing config and rebuilding). In theory, you
could drop the 'make clean', and the depend system will rebuild
anything relevant to the changed configs, but it is a bad idea to
count on this. It *will not* catch any changes to actual source
files, and in many cases will not catch all the config changes. A
munged kernel is the result.
As a rule of thumb...
make mrproper should be used *whenever* the kernel has been patched,
and whenever you untar a new kernel. This ensures you start from a
clean config. (patching may update the src, but can leave the user
generated configs in an unclean state depending on the changes made by
the patch).
I am strongly against saving kernel configs across kernel versions or
patching... If you want to save a config to use against the *exact*
kernel it was generated by, fine, this is useful, but *never* use it
against another kernel version. The configs are generated against
data within the kernel, any version update or patch can invalidate
portions on the config, leaving you with a game of chance as far as
the kernel build goes.
I cannot rant enough about how many hard to trace problems are caused
by this kind of thing. 9 out of 10 times you are fine, its the 10
time that bites you in the ass, specially because it is usually an odd
hard to trace breakage. One should alwasy enshure a clean build
environ and procedure, a couple extra precautions each time are
trivial, but can save you days of pain later.
-- I route, therefore you are.--------- To unsubscribe, send email to <aklug-request@aklug.org> with 'unsubscribe' in the message body.
This archive was generated by hypermail 2a23 : Thu Jul 04 2002 - 00:59:56 AKDT