[CMake] two more problems with dependencies
Alexander Neundorf
a.neundorf-work at gmx.net
Thu Jan 5 16:01:44 EST 2006
Hi,
> Von: Brad King <brad.king at kitware.com>
...
> The test case you sent gives
>
> CMakeFiles/hello.dir/main.o: /home/kingb/Temp/cmakegen/main.cpp
> CMakeFiles/hello.dir/main.o: /usr/include/stdio.h
Yes, this is true. But there is also this code in cmDependsC.cxx, Scan():
// Get the file being included.
UnscannedEntry entry;
entry.FileName = m_IncludeRegexLine.match(1);
if(m_IncludeRegexLine.match(2) == "\"")
{
// This was a double-quoted include. We must check for the
// file in the directory containing the file we are scanning.
entry.QuotedLocation = directory;
entry.QuotedLocation += "/";
entry.QuotedLocation += entry.FileName;
}
which does not check and so generates a wrong QuotedLocation
(as can be seen in the cache contents includecache.CXX). Which at least
isn't completely correct.
> This is the correct behavior. Unless generated.h actually includes
> blah.h then the main.o file does not depend on it. If blah.h changes
> then generated.h will re-generate and then main.o will be recompiled.
> Besides, CMake has no way to know that blah.h is a valid C file unless
> it is included. For all CMake knows the custom command is depending on
> some binary file with information for the custom command's executable.
Hmm, I know I had today a problem with a uic file not being rebuilt and
thought this would be the reason. I'll investigate more tomorrow.
Bye
Alex
--
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
More information about the CMake
mailing list