Re: [kbuild-devel] Re: State of the new config & build system

[Martin Mares]

Hi Keith,

> The main reason is to convert absolute dependency names to $(xxx)
> followed by a relative name, where xxx is one of the KBUILD_OBJTREE or
> KBUILD_SRCTREE_nnn variables.  This conversion allows users to rename
> their source and object trees and to compile on one machine and install
> on another over NFS without being bitten by absolute dependencies.  I
> really need to do that conversion using the current values of the
> kbuild variables, the variables might have changed on the next make.

Yes, I understand, but this could be done as well at the start of the
make run, couldn't it?

> My new design for module symbol versions requires that the version data
> be stored immediately after the compile.  That also requires processing
> after each compile using the current environment.

This sounds worse ... damned modversions, I still think it was one of the
biggest mistakes in Linux history and an one which will be probably very
hard to get rid of.  Anyway, why do you need to process it immediately?

Have a nice fortnight
-- 
Martin `MJ' Mares   <[EMAIL PROTECTED]>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Minimalist definition of maximalism: `more!'.

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

Re: [kbuild-devel] Re: State of the new config & build system

[Martin Mares]

Hi Keith,

> That is exactly what kbuild 2.5 does.  The slowdown occurs when
> massaging the -MD dependencies from absolute names to relative path
> names.  To support separate source and object trees, renaming of trees,
> different names in local and NFS mode etc., the massage code needs a
> list of where all the files are before it can convert the absolute
> dependencies produced by gcc.  Reading and indexing that file for every
> compile is _slow_.

I didn't follow the thread from the very beginning nor did I study
your makefiles carefully, because I don't have much time for kernel
hacking these days, but maybe I won't miss the pond :)

Is there any reason for processing all the files for each compile
instead of merging them to a single file once at the start of the make?

I use it in one of my projects, there is the relevant part of the
Makefile:

# Black magic with dependencies. It would be more correct to make "depend.new"
# a prerequisite for "depend", but "depend.new" often has the same timestamp
# as "depend" which would confuse make a lot and either force remaking anyway
# or (as in current versions of GNU make) erroneously skipping the remaking.

-include depend

depend: force
if [ -s depend.new ] ; then build/mergedeps depend depend.new ; >depend.new ; 
fi

force:

# Implicit rules

obj/%.o: %.c
DEPENDENCIES_OUTPUT="depend.new $@" $(CC) $(CFLAGS) -c -o $@ $<

The DEPENDENCIES_OUTPUT mode is much more convenient than gcc -Mx as it
avoids scattering the relevant information over many files. The mergedeps
script is a simple Perl script which takes care of merging the dependencies
gathered during the previous run of make to the depend file for the next
run. It can do a lot of fixups and translations, here is a trivial
example:

#!/usr/bin/perl

@ARGV == 2 or die "Usage: mergedeps  ";
foreach $a (@ARGV) {
open F, "$a" or next;
$t = "";
while () {
$t .= $_;
if (! /\\$/) {
($t =~ /^(.*):/) || die "Parse error at $t";
$rules{$1} = $t;
$t = "";
}
}
close F;
}
open(F,">" . $ARGV[0]) || die "Unable to write output file";
foreach $a (sort keys %rules) {
print F $rules{$a};
}
close F;

Have a nice fortnight
-- 
Martin `MJ' Mares   <[EMAIL PROTECTED]>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Light-year? One-third less calories than a regular year.

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel