[CMake] Ada and CMake

[Alan W. Irwin]

On Brandon's advice I experimentally tried to replace the execute_process
method of testing gnatmake by use of the first form of TRY_COMPILE to test
the Ada form of ADD_EXECUTABLE, but I ran into the following error message:

Attempt at a recursive or nested TRY_COMPILE

Here is the CMakeLists.txt file that I create for this first form of
try_compile.

*********
set(CMAKE_MODULE_PATH
/home/software/plplot_cvs/HEAD/plplot_cmake/cmake/modules)
project(test Ada)
add_executable(testadacompiler testadacompiler.adb)
*********

I need to set CMAKE_MODULE_PATH to point to the location of my Ada support
modules.  The project(test Ada) command is required, otherwise the
Ada language is not recognized by CMake.  But that in turn executes
the TRY_COMPILE command in CMakeTestAdaCompiler.cmake which leads to an
obvious infinite recursion.

This leads to the following question:  How is the infinite recursion of
TRY_COMPILES avoided for (say) the fortran case? 
CMakeTestFortranCompiler.cmake does use the second
form of TRY_COMPILE which creates a CMakeLists.txt file on the fly.  Here is
that file in the Fortran language case:

*********
PROJECT(CMAKE_TRY_COMPILE Fortran)
SET(CMAKE_VERBOSE_MAKEFILE 1)
SET(CMAKE_Fortran_FLAGS "    ${COMPILE_DEFINITIONS}")
INCLUDE_DIRECTORIES(${INCLUDE_DIRECTORIES})
LINK_DIRECTORIES(${LINK_DIRECTORIES})
ADD_EXECUTABLE(cmTryCompileExec
"/tmp/Fortran/build_dir/CMakeFiles/CMakeTmp/testFortranCompilerF90.f90")
TARGET_LINK_LIBRARIES(cmTryCompileExec ${LINK_LIBRARIES})
*********

I cannot see any fundamental difference between this test CMakeLists.txt
file generated in the Fortran case and the previous CMakeLists.txt file used
for the Ada case.

So how does Fortran (and C, and C++) avoid the TRY_COMPILE infinite
recursion?  Whatever it is, I have obviously missed it for my experimental
Ada language support or some core change needs to be made to CMake itself.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________