Sure I understand that.
> >CFLAGS was only an example, think if I change CC or EXTRAVERSION, but, as
> >said in the earlier email, I doubt an EXTRAVERSION change would work
> >without a full distclean in between anyways.
>
> Of course it works. EXTRAVERSION is only a human readable string used
> by 15 sources (via UTS_RELEASE) and by the various logo.h files.
> Changing EXTRAVERSION has no effect on executable code, it only affects
> display fields. Any other files changed at the same time as
> EXTRAVERSION (say by a patch) will be recompiled, based on the
> timestamp changes. Adding a patch which changes EXTRAVERSION does not
> require a full recompile, which is why the existing system is broken.
I didn't expected it to work including module versioning without a full
recompile, but good to know.
> I admit that kbuild 2.4 does not correctly handle changes to CC, if you
> "make CC=gcc" then "make CC=kgcc", the kernel is not rebuilt. You must
> manually make distlean or mrproper when changing CC. Note that
> overriding flags on the command line does not change the Makefile so
> you cannot rely on the Makefile timestamp to detect command changes,
>
> IOW a check for Makefile timestamp is both overkill (it recompiles too
> much) and incomplete (it does not detect command line overrides). BTW,
> kbuild 2.5 gets this right.
That sounds fine. Of course the only regression could be the build time.
Do you have a benchmark on the build time with kbuild 2.5 applied to
2.4.10 compared to the build time of 2.4.10?
>
> module.h currently uses the full UTS_RELEASE which includes
> EXTRAVERSION but that is spurious, modutils ignores EXTRAVERSION when
> loading a module. modutils only cares about VERSION, PATCHLEVEL and
> SUBLEVEL.
Well again EXTRAVERSION was just an example, SUBLEVEL was the same
problem as EXTRAVERSION for me, I mean after you apply an -ac patch that
for example goes backwards in the SUBLEVEL, do you recompile everything
or do you just run make after your Makefile patch is applied to the
kernel?
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/