[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