On Tuesday 11 of August 2009 11:55:19 Kamil Dudka wrote: > On Tuesday 11 of August 2009 11:40:45 Christopher Li wrote: > > What is the significant of making every header file self compilable? > > Unlike the kernel header files exported to user space, which usually > > have self contained meaning. Most of these header file have tight > > interaction with each other. I don't think it make sense for other sparse > > application to just use one of the header file. > > > > Enforcing each header file to be self compilable will result in a lot > > of unnecessary include. Gcc needs to include "symbol.h" many times > > just to skip over it. Take a look at pre-process.c. It is not exactly > > trivial. It needs to scan the token to find out the end of the if > > scope. In this case, it might be better just let other header > > file depend on "symbol.h". I agree processing of multiple-includes could be painful for the SPARSE preprocessor. But you don't solve it by avoiding multiple-includes in the SPARSE code itself. If you want to pass the SPARSE code through SPARSE, it's small enough to not bother us with performance. But you have absolutely no control of the foreign code processed by SPARSE and there the performance impact could be significant. I think this is the way to go: http://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html Kamil -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
