[CMake] CMake 2.8.6 --> 2.8.8 New TryCompile Fails on GCC-GNAT Ada Linking

[Alan W. Irwin]

On 2012-07-02 12:25-0400 Matthew Schuchard wrote:

> 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.

Agreed!

>
> 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.

I cannot confirm the issue.  I just tried a complete PLplot build and
test from scratch with CMake-2.8.8, and all was well, i.e., each of
our ~30 standard plots had the same PostScript results for each of our
supported computer languages (including Ada).  This is a fairly
comprehensive test of all our supported languages since something like
400 different plot files are involved.

It has been a very long time since I looked at Ada language support,
but I do know that Ada language support in CMake is rather tricky (see
my agreement with your remarks above) so I suspect the issue is you
are doing something that is less robust against CMake changes than the
way that PLplot uses the Ada language support that was designed by me
many years ago.  So to solve this issue, I suggest you look very
carefully at how PLplot does things (in
cmake/modules/language_support/cmake, bindings/ada and examples/ada in
our PLplot-5.9.9 release or our svn trunk version), and follow that
slavishly.  Feel free to contact me off list if you have further
questions on how PLplot implements Ada language support _and_ uses
that language support.

By the way, my C++ skills are limited so I have never understood the
workings of the general language support implemented in C++ by CMake,
but clearly those inner details need to be updated to handle language
such as Ada (and OCaml) whose builds are a bit more complex than the
simple compile and link that is used for most compiled languages.

For example, Ada builds consist of compiling (which generally produces
object files as well as ALI (Ada Library Information) files, binding
(which scans all the ALI files to make sure everything is consistent),
and linking.  The location of the ALI files is one Ada language
support issue.  Fortran 95 has a similar issue with Module files that
are generated by the compiler, and my understanding is that special
support for the location of Fortran module files is built into CMake
at the C++ level, and something similar needs to be done for the ALI
files required for Ada builds.

Another big issue for Ada is that gnatmake (the application that
combines all the different complex build steps for Ada together
including complete dependencies) is clearly a "headache-inducing
compiler with poorly conceived input/output file behavior and
arguments".  That said, gnatmake does have to do an enormous amount so
there may be no other choice than a large number of different kinds of
arguments in different positions that affect its behaviour.
Thus, the current status is (quoting from my CMakeAdaInformation.cmake
file)

"In sum, you have to be careful of your target name, the nominal source
file name has to be compilable, but otherwise it is ignored, and you
must specify the required -aI and other GNAT_EXECUTABLE_BUILDER =
gnatmake options using LINK_FLAGS specified with
set_target_properties."

To avoid such workarounds in the future, the C++ level of CMake needs
to be generalized to support more than <TARGET>, <LINK_FLAGS>, etc.,
to allow full use of gnatmake.  If one of the CMake developers is
interested in doing such a generalization, see "info gnat_ugn.info.gz"
for more information about all the possible position-dependent parts
of the gnatmake command.

> 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.

Actually, my understanding is this is done for a reason in the binding
part of the build to assure exact dependencies and absolute consistency.

>
> 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.

PLplot does something similar, see examples/ada/CMakeLists.txt.
However, we _do_ specify the -aI flag specifying the directory
location of the source file so your lack of -aI flag may be the source
of the issue you have found.  Also note my good CMake-2.8.8 results
reported above were for a separate build tree which definitely makes the
-aI flag necessary since the build is occurring in that tree rather
than in the source tree.  But the -aI flag may be needed even if
you do a build in the source tree.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________