The executable name does in fact have to match the name of the source file.
I could get into details, but the short summary is that gcc-gnat is a
very headache-inducing compiler with poorly conceived input/output file
behavior and arguments.
As per the first email, the general Ada link statement in
CMakeAdaInformation is:
"${CMAKE_Ada_BUILDER} <LINK_FLAGS> <TARGET_BASE>.adb -cargs <FLAGS>
-bargs ${CMAKE_Ada_BIND_FLAGS} -largs <CMAKE_Ada_LINK_FLAGS>
<LINK_LIBRARIES>"
and the free to use one by Allen Irwin(?) follows the same basic
methodology for linking, meaning his will break now also. You can see
why the target name has to match the primary source file name. If you
are wondering about executables with multiple source files, gnatmake
hilariously goes through and builds whatever other Ada files it think
are necessary for the executable based on the primary source file.
So this worked before because the generated function was:
ADD_EXECUTABLE(cmTryCompileExec
"/users/ms503/gtsims/bld/CMakeFiles/CMakeTmp/cmTryCompileExec.adb")
which generated a link statement:
/usr/bin/gnatmake cmTryCompileExec.adb -cargs
-gnatec/path/to/gnat.adc -g -Wall -bargs -largs -rdynamic
whereas now it is:
/usr/bin/gnatmake cmTryCompileExec162931069.adb -cargs
-gnatec/path/to/gnat.adc -g -Wall -bargs -largs -rdynamic
Which fails due to non-existent file.
This also works because there is no need for the -aI flag instructing
gnat as to the location of the input source file, since TryCompile
builds in /path/to/CMakeTmp/, which is where the source file is located.
For all the local project CMakeLists, I have an overloaded
add_ada_executable function which builds a nominal "hello world" object
with gnat for the compilation step (free to use CMake Ada does something
similar) and then asks gnatmake to do all the heavy lifting for the
executable during build/bind/link. Building objects for linking into a
library is performed with gnat without any hacks and/or shenanigans.
If there was a way to continue naming the test file the same as the
TryCompile target, I would be set.
The other possibility is to delve into the GNAT 4.1.x --> 4.4.x changes
and see if any sanity was introduced into input/output file behavior and
arguments.
On 07/02/2012 11:38 AM, Bill Hoffman wrote:
On 7/2/2012 11:22 AM, Matthew Schuchard wrote:
Attached tarball of CMakeTmp after failed Ada TryCompile.
Relevant from CMakeTestAdaCompiler:
IF(NOT CMAKE_Ada_COMPILER_WORKS)
PrintTestCompilerStatus("Ada" "")
FILE(WRITE
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/cmTryCompileExec.adb
"with Ada.Text_IO;\n"
"use Ada.Text_IO;\n"
"procedure cmTryCompileExec is\n"
"begin\n"
"Put(\"Hello World\");\n"
"end cmTryCompileExec;\n")
TRY_COMPILE(CMAKE_Ada_COMPILER_WORKS ${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/cmTryCompileExec.adb
OUTPUT_VARIABLE OUTPUT)
SET(Ada_TEST_WAS_RUN 1)
ENDIF(NOT CMAKE_Ada_COMPILER_WORKS)
So, the generated CMake file looks like this:
ADD_EXECUTABLE(cmTryCompileExec2054790633
"/users/ms503/gtsims/bld/CMakeFiles/CMakeTmp/cmTryCompileExec.adb")
That does not look bad to me. However, since you did not include the
Platform ADA files you are using, the problem could be there. Does
the executable name have to match the .adb file?
-Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
