[CMake] New compiler module for Digital Mars' D language -- one problem remains!

[Alexander Neundorf]

On Tuesday 28 August 2007 20:56, you wrote:
> Hey Alexander,
>
> >> Will this patch make it into CVS and eventually an upcoming CMake
> >> release?
> >
> > Done. It will be in cmake 2.6.0.
>
> Excellent!  Thanks again for the quick work on this.
>
> >> I'm also curious, what would it take to get the D modules into the
> >> default CMake install?  Of course I would be willing to take
> >> maintainership of them.
> >
> > That and one or more tests in CMake/Tests/ so it can be tested every
> > night.
>
> I have no problem creating some test cases however the D compiler module
> is a bit complicated.  It supports two different compilers, and two
> different standard library sets (which are incompatible with each
> other).  I'm curious how automated testing might work.  Would there be a
> machine that would get the D compilers loaded onto?

Yes.
The test should at least build an executable from more than one file, and a 
library from more than one file, and link them together.
The more it tests, the better.

I had a look at the files in svn.
Can you please have a look at the C/C++ support files in current cmake cvs ?
They have been reworked a bit, among others to support cross compiling, 
a "compiler id" and more fine tuning:

Instead of searching for ranlib, there is now a CMakeFindBinUtils.cmake which 
does that.

The CMakeDetermine<lang>Compiler.cmake files now try to build a simple 
executable from which a "compiler id" can be extracted, have a look at 
CMakeDetermineCompilerId.cmake and e.g. CMakeCCompilerId.c

This compiler id is then used for loading the compiler specific file (instead 
of just the basename of the compiler).

There is now support for a CMAKE_SYSTEM_PROCESSOR specific file, have a look 
at CMakeCInformation.cmake

The output extension is now set in CMake<lang>Information.cmake and not in the 
configured file, this makes it easier to support toolchains which have 
unusual extensions.

Bye
Alex