[CMake] CMAKE 2.6.0: Wrong dependencies when CMake<LANG>Information.cmake is missing

[Wojciech Migda]

Alexander Neundorf pisze:
> On Sunday 08 June 2008, Wojciech Migda wrote:
>   
>> As it appeared the "." entry was present due to me using user-defined
>> assembler compiler for the build. Commenting out the relevant
>> ENABLE_LANGUAGE command in CMakeLists.txt led to proper behaviour. But
>> why ? I looked at the cmGlobalGenerator::EnableLanguage function and
>> after debugging I noticed that when a check for
>> CMake<LANG>Information.cmake was made, a file which was missing - I did
>> put all assembly compiler definitions into CMake<LANG>Compiler.cmake, a
>> call to GetModulesFile returned an empty string. ReadListFile executed
>> with that empty string did not fail, and that probably led to the "."
>> directory being present in the CMAKE_MAKEFILE_DEPENDS list.
>>     
> Another way to fix this would be to fail if CMake<LANG>Information.cmake is 
> not found, so you would have noticed that something is going wrong. Maybe 
> this would be a better approach, then the support for languages will be more 
> consistent.
>   
Well, that's what I tried to introduce with the patch,although the 
termination doesn't happen immediately after an error is found, but the 
generation continues to the end.
> Bill ?
>
>   
>> I confirmed that by setting the CMAKE_<LANG>_INFORMATION_LOADED variable
>> before execution of ENABLE_LANGUAGE - the dependencies were correct.
>> Nonetheless I'd expect that a fix with additional check for ifpath being
>> empty is introduced in
>> cmGlobalGenerator.cxx/cmGlobalGenerator::EnableLanguage.
>>
>> I've prepared a patch against the 2.6.0 version. Unfortunately I could
>> not find the patch format instructions for cmake, so I took those for
>> linux kernel (diff -up).
>>     
>
> Looks ok.
>
> I had a look at your files.
> What system are you building for ? 
> Is it some rolled-your-own OS or some OS generally available ? If so, we could 
> add support for it to cmake directly.
>   
It's an embedded system with it's own proprietary OS.
> Why do you need CMAKE_FORCE_[C|CXX]_COMPILER() ?
>   
I'm cross-compiling on Cygwin/U*IX (c, c++, asm)
> Why do you need to set CMAKE_[C|CXX]_OUTPUT_EXTENSION_REPLACE to true ?
>   
Otherwise the object file names would have a form <source_filename>.o, 
e.g. foo.c.o, or irq.S.o . It didn't suit me for some legacy backward 
compatibility reasons (e.g. linker scripts with hardcoded paths).
> This looks like there is something not working which should work.
>   
Since eventually  I got it working I took some things for granted, 
although they seemed more like black magic to me. I blamed the 
cross-compiling framework but if you say it might be some cmake 
deficiencies itself, then I'll look through the files to see if I could 
report some more suspicious behaviour.

Thanks,

Wojciech

> Bye
> Alex
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
>
>   

---------------------------------------------------------------
Sprawdz jak zdobyc zdrowy usmiech!
Kliknij >> http://link.interia.pl/f1e26