[CMake] resetting CHECK_INCLUDE_FILE
Eric Noulard
eric.noulard at gmail.com
Wed Nov 8 09:09:16 EST 2006
2006/11/8, Peter Soetens <peter.soetens at fmtc.be>:
> On Wednesday 08 November 2006 11:32, Eric Noulard wrote:
> > << re-sending to ML with complement >>
> >
> > The result of the check may be cached.
> >
> > If you install/remove software on which your build depends
> > I think the better you have to do is to throw the CMake cache all together
> > and re-run CMake in a pristine build tree.
>
> That's dull if you already made some changes,
I won't argue your point of view but just want to precise mine.
If you are talking about "Source Tree" changes
NOTHING prevents you from creating ANOTHER build tree
pointing to just the SAME source tree.
It is SIMPLE and FAST (as long as your build/compile time is not too high) :
mkdir new_build_tree
cd new_build_tree
cmake <path_to_source_tree>
make
This "may" be slightly more complicated if your particular
build has CMake "OPTION" values which are not the default ones
but in both cases you do not lose your source tree changes.
> or even have a working build,
If the previous build "works" the second will too, unless
the newly discovered lib breaks the build.
> but want to test the same configuration with this one library extra
> installed.
>
> I just found out about the thread which says to use FIND_XXX instead. That
> macro covers my needs, although the -NOTFOUND thing is not yet documented...
I just reread-it and your are right it seems to fullfill your need
and I missed that.
Nevertheless I wanted to underline that CMake
makes it really EASY and FAST to create a fresh build tree
so that tracking the fact that using
FIND_xxx instead of CHECK_xxx is a better way of supporting
newly installed libs without full rebuild may not be worth the pain.
>Thanks anyway,
You're welcome.
And thanks to you for the FIND_xxx pointer.
--
Erk
More information about the CMake
mailing list