<div dir="ltr">It&#39;s easy (in this case at least) to modify the test program.  Replace<div>the second line of this program (from CMakeTestFortranCompiler)<br><div><br></div><div><div>      PROGRAM TESTFortran90</div><div>
      stop = 1 ; do while ( stop .eq. 0 ) ; end do</div><div>      END PROGRAM TESTFortran90</div></div><div><br></div><div style>with</div><div style><br></div><div style><div>      integer stop; stop = 1 ; do while ( stop .eq. 0 ) ; end do</div>
<div><br></div><div style>(Note that the implicit typing rules of Fortran meant that stop was</div><div style>a real variable in the original program -- not that it particularly mattered.)</div><div style><br></div><div style>
In other Fortran test code, including that specifically for F77 compilers,</div><div style>just explicitly declaring the types of all variables will keep the &quot;-u&quot; flag</div><div style>from breaking the test.</div>
<div style><br></div><div style>I think there is a larger issue here though.  I assume that the intent</div><div style>of CMakeTestFortranCompiler is generally to probe the language capabilities</div><div style>of the compiler.  If so, I can imagine there being certain flags that would be</div>
<div style>relevant to this, like a &quot;-f95&quot; flag which sets the compiler to F95 language level,</div><div style>while others like debug or optimization flags that would be totally irrelevant</div><div style>and perhaps shouldn&#39;t even be used to avoid unintended consequences.</div>
<div style>Is there a second set of variables (CMAKE_Fortran_FLAGS_DEBUG e.g.)</div><div style>that ought to be used for the latter category of flags which get appended</div><div style>automatically to the flags from CMAKE_Fortran_FLAGS when compiling</div>
<div style>actual project code?  (I&#39;m still very new to cmake)</div><div style><br></div><div style>-Neil</div><div style><br></div><div style><br></div><div><br></div></div><div><br></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Jul 1, 2013 at 9:20 AM, Brad King <span dir="ltr">&lt;<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 6/30/2013 11:10 PM, Neil Carlson wrote:<br>
&gt; Why is that module using CMake_Fortran_FLAGS at all?  Shouldn&#39;t it be<br>
&gt; invoking the bare compiler when it runs its tests?  Or am I misusing<br>
&gt; CMake_Fortran_FLAGS?  Should I be defining its value at a later stage in<br>
&gt; the cmake files?<br>
<br>
</div>The test for a working compiler is building a tiny project<br>
using all the settings that will be used in the main project.<br>
This checks up front that things are configured correctly for<br>
the build you&#39;re trying to do rather than waiting for a build<br>
failure much later.<br>
<br>
CMAKE_Fortran_FLAGS could have flags affecting the target<br>
architecture and such, so we need to use them for the test.<br>
<br>
You can work around this by waiting until after the project()<br>
or enable_language() command that loads Fortran support to<br>
add the -u flag.  However, if we can modify the test code that<br>
CMake uses to verify the toolchain so that it works with that<br>
flag then we should do so.  How might the tiny project source<br>
have to be modified to work?  Will it still be compatible with<br>
F77 compilers?<br>
<span class="HOEnZb"><font color="#888888"><br>
-Brad<br>
</font></span></blockquote></div><br></div>