So I am back for more CMake fun in attempting to get it working with our
massive and convoluted product. I am now trying to use my office
computer to configure and build our software, and am hitting an issue
with the new TryCompile in CMake 2.8.8 (or possibly 2.8.7 if it was
introduced then).
On 7/2/2012 10:22 AM, Matthew Schuchard wrote:
So I am back for more CMake fun in attempting to get it working with our
massive and convoluted product. I am now trying to use my office
computer to configure and build our software, and am hitting an issue
with the new TryCompile in CMake 2.8.8 (o
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
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 stateme
On 7/2/2012 12:25 PM, 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.
I thought the change had been to preserve prior TryCompiles for
debugging purposes.
Would it be too cynical to propose some OS #ifdefs above the code?
Although you mention file systems, so this an NTFS issue also?
Of course, at the end of the day this is what breaks GNAT TryCompile:
- targetName
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.
On 07/06/2012 07:46 AM, Matthew Schuchard wrote:
> I thought the change had been to preserve prior TryCompiles for
> debugging purposes.
> Would it be too cynical to propose some OS #ifdefs above the code?
> Although you mention file systems, so this an NTFS issue also?
We don't know what causes
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 __li
