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

[Alexander Neundorf]

On Tuesday 10 June 2008, Wojciech Migda wrote:
> 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.

Ok. I committed a slightly modified version.

> > 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.

"own proprietary OS" == you/your company wrote it or an RTOS one can buy ?
Adding support for some commercial RTOS like e.g. VxWorks to cmake would be 
ok.

> > Why do you need CMAKE_FORCE_[C|CXX]_COMPILER() ?
>
> I'm cross-compiling on Cygwin/U*IX (c, c++, asm)

No, I mean, why do you need to FORCE it ?
In most cases the compilers should be able to build a simple executable for 
the target, also when cross compiling.
What fails ?

> > 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).

Ah, ok.

> > 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.

Yes, please :-)

Alex