Improved way to treat config.h

[GoogleCodeExporter]

Given:
==> config.h <==
/* #undef HAVE_SOMETHING */

==> test.c <==
#include "config.h"

#ifdef HAVE_SOMETHING
void f() {
}
#endif
===

IWYU suggests to remove config.h. Such a config.h is typical with many build 
systems (e.g. cmake). One can add a pragma-keep to the config.h but that isn't 
nice because 1) there might be very many places and 2) it means that config.h 
isn't automatically removed if HAVE_SOMETHING isn't used anymore.

Possible solutions:
1) Given that this type of config.h is common it would be nice if IWYU would 
understand the comment and would understand that config.h is needed.
2) Have the possibility to mark a certain file as "keep" in the mapping file. 
That would solve issue 1 but not 2 from above.
3) Add a new pragma which could be added to the #undef line. Not quite as nice 
as solution 1 but would solve both issues from above.

Original issue reported on code.google.com by rol...@rschulz.eu on 14 Sep 2014 at 6:29

[GoogleCodeExporter]

Another possible solution:
4) Add support to fix_includes.py that it process the output of multiple IWYU 
runs and then only removes those includes which each run marked for deletion. 
This would allow one to run IWYU with the include path set to multiple 
different config.h files and as long as those cover any of the settings set at 
least once it would work. This is not as nice because it would require that one 
have those proper config.h files, but it would also solve the issues that 
includes other than the config.h itself are removed if they are only needed by 
code inside and #ifdef or #ifndef.

Original comment by rol...@rschulz.eu on 14 Sep 2014 at 6:37

[GoogleCodeExporter]

Interesting problem.

I was thinking of special treatment for "#if HAVE_.*", but I think it's an 
autoconf convention, Clang/LLVM's CMake system uses "LLVM_ENABLE_" as a prefix 
instead, and our codebase at work has settled for "XYZ_ENABLE_" as well.

Parsing comments doesn't sound very sustainable either.

I've been thinking about making the mapping files more general metainfo files 
containing things like keep, export, etc, so we can specify it both as pragma 
comments and externally. But as you say, keep doesn't really solve this 
generally.

I wonder if you could script something that merged the output of multiple IWYU 
runs according to your first comment? That way you could run IWYU in all 
configurations, merge the results and then run fix_includes.py as-is on the 
merged log.

I don't have any better general-purpose solutions here, more ideas welcome!

Original comment by kim.gras...@gmail.com on 20 Sep 2014 at 2:04