Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
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
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
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
Original issue reported on code.google.com by
annu...@gmail.com
on 29 Mar 2011 at 1:00