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

[Matthew Schuchard]

On 07/09/2012 08:41 AM, Brad King wrote:
>> Of course, at the end of the day this is what breaks GNAT TryCompile:
>>
>> - targetName = "cmTryCompileExec";
>>
>> But not removing that line of code would seemingly break everything else.
>>
>> So the path of least resistance cynical code change proposal:
>>
>> #ifdef __linux__
>> targetNameBuf = "cmTryCompileExec";
>> #else
>> sprintf(targetNameBuf, "cmTryCompileExec%u",
>>              cmSystemTools::RandomSeed());
>> #endif
>>
>> With a nice comment like "so this annoying coding language Ada and its
>> terribly conceived compiler GNAT can be supported on Linux" or some such.
> I'd rather it be something like
>
>   if(this->Makefile->IsOn("CMAKE_"+lang+"_TRY_COMPILE_NO_RANDOM"))
>
> so your platform files can control it.
>
> -Brad
Well I mean, you are you and I am me, so of course you would conceive of 
a better solution.  I feel like everyone involved would prefer something 
a bit more... robust though.

Alan Irwin said:
"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."

This would be rather awesome and I agree 100%.  If we could use <SOURCE> 
in the link executable general statement, that would probably be a 
robust solution.  Both Irwin and I use a "dummy" source for the 
compilation step in an executable creation for Ada (I use GNAT for 
object compilation for libraries though and I forget if Irwin uses that 
or also uses GNATMake with a dummy source for those situations).  If 
there was some way of using GNAT for the compilation step and then 
GNATBind and GNATLink for the link step, that would be rather awesome.  
I tried several different methods to enable that in CMake though, and it 
failed due to lack of available intrinsic variables and possibly also 
GNAT conventions.  I will mention how awesome it was that I could 
semi-colon delimit the statement in the .cmake file successfully 
(SET(CMAKE_Ada_LINK_EXECUTABLE "gnatbind foo; gnatlink foo").

I mean, right now to enable GNATMake to access already compiled objects 
needed for the executable to attempt to not force it to unnecessarily 
rebuild, I do something like:

list(GET ARGN 0 primarylibrary)
set_target_properties(${target} PROPERTIES LINK_FLAGS 
"-aO${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_FILES_DIRECTORY}/${primarylibrary}.dir 
${includeflags} -aI${CMAKE_CURRENT_SOURCE_DIR}")

in a CMake function, which should make everybody cringe.  It would be 
great to just:

SET(CMAKE_Ada_COMPILE_OBJECT
     "<CMAKE_Ada_COMPILER> <FLAGS> -c <SOURCE> -o <OBJECT>")

SET(CMAKE_Ada_LINK_EXECUTABLE
     "${CMAKE_Ada_BINDER} <OBJECTS> ${CMAKE_Ada_BIND_FLAGS}; 
${CMAKE_Ada_LINKER} <OBJECTS> <LINK_FLAGS> <CMAKE_Ada_LINK_FLAGS> 
<LINK_LIBRARIES>")

although I doubt the above would work in the given syntax even with the 
enhanced capabilities, but I list just as a general concept.  This would 
be clean, allow for no unnecessary rebuilding, no dummy source 
compilation, and less/no hacks/kludges.

I guess the time-cost/Ada-capability-benefit derivative maximum lies at 
enabling the <SOURCE> tag for the LINK EXECUTABLE statement.  I assume 
(possibly incorrectly), that this would be quick for you guys to 
implement, and it would fix my issues as well as allowing both of us to 
make our Ada toolchains less kludgey.

For a fully clean Ada toolchain that could possibly even be officially 
supported by CMake, we would need probably more intrinsic variables in 
the general COMPILE/LINK statements, and some experimentation to ensure 
efficiency and accuracy.

Thanks for the attention thus far by the way guys.