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@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
---------------------------------------------------------------
Sprawdz jak zdobyc zdrowy usmiech!
Kliknij >> http://link.interia.pl/f1e26
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
