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
__________________________
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
