[CMake] Ada and CMake

Alan W. Irwin irwin at beluga.phys.uvic.ca
Wed Mar 14 19:37:50 EST 2007


On 2007-03-05 12:20-0500 Bill Hoffman wrote:

> Alan W. Irwin wrote:
>> Anyhow, with the gnatmake test, the first form of TRY_COMPILE is required,
>> and so far I have not been able to figure out how to avoid the infinite
>> TRY_COMPILE issue with that form.  Thus, I would really appreciate an
>> answer for how that issue is avoided for the second TRY_COMPILE form
>> for C, C++, Fortran, and a compile-only Ada test.
> I have not had time to look into the problem in detail.  It sounds like there 
> is a bug in the second form of try_compile.  One quick way to verify this 
> would be to change CXX or C to use the second form of try_compile and see if 
> it has the same problem.   If so, please create a bug for this.  Thanks.
>

OK, I have finally figured this out after tinkering with it for what seems a
very long time.  The bad behaviour I was seeing for the _first_ (not second)
form of TRY_COMPILE was not due to a bug. Instead, I was the victim of poor
documentation of the first form of TRY_COMPILE.

I am not an expert C++ programmer by any means, but I was able to sufficiently
follow the logic of cmTryCompileCommand.cxx to understand what is going on
and work around the "Attempt at a recursive or nested TRY_COMPILE in
directory " error message I was encountering for the first form of
TRY_COMPILE.

Note, srcFileSignature is true for the second form of TRY_COMPILE and
false for the first form.

For the second form we have the following code fragment:

tmpString = argv[1];
tmpString += cmake::GetCMakeFilesDirectory();
tmpString += "/CMakeTmp";
binaryDirectory = tmpString.c_str();

This means ${CMAKE_FILES_DIRECTORY}/CMakeTmp is appended to the binary
directory specified by the user for the second form of TRY_COMPILE, but not
for the first.  Thus, you must use
${binary_directory}${CMAKE_FILES_DIRECTORY}/CMakeTmp for the first form of
TRY_COMPILE (where ${binary_directory} is the binary directory specified for
the second form) in order for the first form binary directory to be
equivalent to that of the second form.

For the C and Fortran language tests, the binary directory of
${CMAKE_BINARY_DIR} is used (for the second-form of TRY_COMPILE).  Thus,
without documentation and before I dug through the code, I naively thought
the binary directories were equivalent between the first and second forms so
I used ${CMAKE_BINARY_DIR} for the binary directory for the first
form of TRY_COMPILE.

That meant I ran into the error generated by the following code:

  if (!strcmp(binaryDirectory,mf->GetHomeOutputDirectory()))
     {
     cmSystemTools::Error(
       "Attempt at a recursive or nested TRY_COMPILE in directory ",
       binaryDirectory);
     return -1;
     }

and I didn't know how to get past that error until now which is to replace
${CMAKE_BINARY_DIR} by ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp
for the binary directory for my Ada compiler tests using the first form
of TRY_COMPILE

My Ada compile test now works properly (see
http://plplot.cvs.sourceforge.net/plplot/plplot/cmake/modules/CMakeTestAdaCompiler.cmake?view=markup)
when using the first form of TRY_COMPILE so all is well that ends well.

However, clearly the documentation of that form should be drastically
improved (including a prohibition on specifying a binary directory of
${CMAKE_BINARY_DIR}), and the documentation of the second form (which is
otherwise fine) should note the automatic appending of
${CMAKE_FILES_DIRECTORY}/CMakeTmp to the binary directory specified by the
user.

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
__________________________


More information about the CMake mailing list