How feasable would it be to extend CML2 and clean up the code base to
avoid having to do a make dep / make clean to be reasonable sure stuff is
consistent?
It seems to me that using 'make' (which is arguably broken for working at
a file level rather than a line level), we could hack this by having CML2
write a different file for each configuration option (ack!), that sets the
value to true or false. The top level config.h file would #include all of
these generated files, and CML2 would only write files when they change
(similar to autoconf). Then when 'make dep' does its work, it makes each
file a dependency, and if a config option is changed, only files that
depend on it are rebuilt.
Seems like a utopia. :) Okay, here are the problems as I see it:
1. Explosion in number of .h files generated by CML2 and occupying space
on HD. If large "clusters" are used, this could occupy a large amount of
space. (but I believe EXT/2 is smarter than that?)
2. Preprocessor will have to dig through *all* of these files when
compiling, which might slow things down a bit. After the first .c file to
compile though, they should stay in the disk cache.
So, love it, hate it? I just dislike having to type 'make clean' when I
do something like enable smp support...
-Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:22 EST