Feature request: allow usage without make -k

[GoogleCodeExporter]

It would be possible to use IWYU in unmodified build process (with IWYU set as 
compiler, of course) if it returned 0 on valid sources and wrote empty output 
file (to satisfy build system).

Original issue reported on code.google.com by annu...@gmail.com on 29 Mar 2011 at 1:00

[GoogleCodeExporter]

The problem with that is that if you wanted to run iwyu again, it would produce 
no output, since the build system would think the build is up-to-date.  I'm 
guessing that would cause confusion, and people would think they're getting a 
clean bill of health from iwyu rather than not having iwyu run at all, so I've 
decided to go with the 'error' route.

Original comment by csilv...@gmail.com on 29 Mar 2011 at 5:49

[GoogleCodeExporter]

The solution I plan to follow for this one is to provide a driver script that 
does both the iwyu run and the fix_includes call.  It will call make -k behind 
the scenes, but the user won't see that.

Original comment by csilv...@gmail.com on 6 Apr 2011 at 8:18

• Changed state: Started

[GoogleCodeExporter]

this seems to be a blocking point to use IWYU with a project compiled with 
cmake (cmake may trigger the compiler to generate some helper files that help 
configure itself: to identify endian, etc...).

Would it be possible to use a mechanism similar to clang/tools/ccc-analyzer? 
This enables to run the analyzer while still compiling the project with the 
standard gcc.

Original comment by emmanuel...@gmail.com on 16 Sep 2011 at 6:42

[GoogleCodeExporter]

It's easy to run the analyzer while compiling with gcc (or with clang), but 
then what happens when you want to run the analyzer again?  You'll have to 
manually run 'make clean' first?  Otherwise, since the build is already done 
the analysis run will be a noop.

I don't know how ccc-analyzer is intended to be used, that it doesn't suffer 
from the same problem, but I am wary of a scheme where it doesn't run iwyu on 
files that you tell it, because it thinks they're already 'done'.  That can be 
hard to debug.

I don't know cmake, but I'd expect there's a way to tell it to use a different 
'local' compiler than 'target' compiler (as if you were cross-compiling).  The 
local compiler would be used for the configure checks, while the target 
compiler would be used to build your project.

It may be worth updating the README to discuss this technique, if you can get 
it to work.

Original comment by csilv...@gmail.com on 21 Sep 2011 at 7:54

[GoogleCodeExporter]

I understand the issue. Being able to run the analyzer only on part of the 
project is nice though. And if using it in a presubmit, not recompiling all the 
project it pretty good too.

Regarding cmake, the cross-compiling route doesn't seem the most simple so I 
solved my issue with 2 simple 'drivers':

/usr/bin/iwyu

#!/bin/sh
IWYU_COMMAND=/llvm-bin/bin/include-what-you-use
COMPILER_COMMAND=/usr/bin/gcc
$IWYU_COMMAND $@
$COMPILER_COMMAND $@

and

/usr/bin/iwyu++

#!/bin/sh
IWYU_COMMAND=/llvm-bin/bin/include-what-you-use
COMPILER_COMMAND=/usr/bin/g++
$IWYU_COMMAND $@
$COMPILER_COMMAND $@

and setting the cmake variables:
CMAKE_CXX_COMPILER               /usr/bin/iwyu++
CMAKE_C_COMPILER                 /usr/bin/iwyu

There is definitely room for improvement, but that might be a useful trick for 
others.

Original comment by emmanuel...@gmail.com on 23 Sep 2011 at 6:02

[GoogleCodeExporter]

I'm glad you found a workaround that serves your needs!  Seems like a good 
trick, to me.

Original comment by csilv...@gmail.com on 23 Sep 2011 at 2:46

[GoogleCodeExporter]

I'm closing this WontFix, though there is a workaround, so hopefully that's ok.

Original comment by csilv...@gmail.com on 25 Oct 2011 at 12:13

• Changed state: WontFix