<br><br><div class="gmail_quote">On Thu, Oct 18, 2012 at 11:32 AM, Szilárd Páll <span dir="ltr">&lt;<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div>
<div class="gmail_quote"><div class="im">On Thu, Oct 18, 2012 at 3:51 PM, Roland Schulz <span dir="ltr">
&lt;<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<div class="gmail_quote">
<div>On Thu, Oct 18, 2012 at 9:19 AM, Szilárd Páll <span dir="ltr">&lt;<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>&gt;</span> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="gmail_quote">
<div>
<div>On Thu, Oct 18, 2012 at 3:12 PM, Roland Schulz <span dir="ltr">&lt;<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>&gt;</span> wrote:<br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<div class="gmail_quote">
<div>On Thu, Oct 18, 2012 at 7:01 AM, Szilárd Páll <span dir="ltr">&lt;<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>That&#39;s correct. The point I was trying to make is that we might end up hearing about this issue in the future if people use CFLAGS just by routine. I fact, I&#39;m not even sure that cmake is not supposed to pick up CLAGS as well and it&#39;s some later cmake
 pass rewriting compiler options is that the current code is trying to overcome, but it ends up loosing some options when CFLAGS is set.
<div><br>
</div>
<div>Any comments? Should CFLAGS work?<br>
</div>
</div>
</blockquote>
</div>
<div>Yes. And I think it mostly works like it should. Environment variables should only be read the first time you run. And it should overwrite any of the default settings. Thus I think we should not set any flags if CFLAGS is set. Sander added that with 0ce2e62b72d2
 to cmake/gmxCFlags.cmake. None of the flags set in that file are added to CMAKE_C_FLAGS if CFLAGS is set.. But the new acceleration depending options (e.g. -mavx) are set even if CFLAGS is set. I think this is wrong. If you agree I can fix that. </div>


</div>
</blockquote>
<div><br>
</div>
</div>
</div>
<div>
<div>Wait a second, if you want to override all flags instead of appending, we might have to change the acceleration detection to drop all acceleration unless the flag that would be added is already in the CFLAGS passed. This sounds a bit awkward, but it&#39;s
 the only way to ensure that one does not end up e.g. with GMX_ACCELERATION=AVX_256, but no -mavx flag passed which will result in nasty compiler errors.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think it is important to be consistent. I&#39;m not sure there is a cmake standard whether CFLAGS should overwrite or append flags. With autoconf we used to overwrite and with gmxCFlags we overwrite. Given that, I don&#39;t think it is a good idea to try to
 be too helpful. I think if the user manually specifies something we shouldn&#39;t mess with it. Nothing is more annoying than a program which does something else then explicitly told. So if I call cmake with explicit set CFLAGS those exactly should be used. If
 anything at all we should give a warning that those flags are probably needed. If we want to have a different variable which means &quot;add those cflags to the default ones&quot; that&#39;s fine. But I think based on the history the meaning of CFLAGS is &quot;use exactly those
 flags&quot; and thus even the acceleration flags shouldn&#39;t be added to it.</div>
</div>
</blockquote>
<div><br>
</div>
</div><div>Well, consistency in this case can be defined in many ways, but in principle I agree. However, by &quot;consistent&quot; you are referring to adherence to common *nix practices. At the same time, I was referring to prioritizing internal consistency, i.e. trying
 hard to not end up with broken configuration.Consequently, if we really want to stick hard &quot;autoconf emulation&quot; (assuming that the CMake behavior expected with CFLAGS is not documented to be the same as with autoconf), we need to *drop* all acceleration and
 probably disable other things (like the gcc 4.4 -O3 bug workaround). </div>
<div><br>
</div>
<div>E.g. given a cmake invocation:</div>
<div>$ CC=gcc CFLAGS=&quot;-foo -bar&quot; cmake</div>
<div>on a Sandy Bridge CPU, we should drop to GMX_ACCELERATION=SSE (because that&#39;s on by default with gcc).</div>
<div><br>
</div>
<div>Of course we can and should issue a warning, but especially if we won&#39;t have the configuration summary implemented for 4.6 (which based on the amount of volunteers is probable), a lot of warnings can go unnoticed in the 100-s of lines long CMake configuration
 output.</div></div></div></blockquote><div> </div><div><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.800000190734863px">I don&#39;t think it makes any sense to automatic disable acceleration based on flags. That is completely counter-intuitive and error prone. I think it is completely normal that if one overwrites something that one can&#39;t expect it to work anymore if one does it incorrectly. But maybe the user does it on purpose. E.g. it is a gcc compiler wrapper which already has avx and so on as flags anyhow. On the other hand the acceleration flags don&#39;t hurt if they are appended twice. So the current approach is probably OK.</span></div>

<div><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><span style="background-color:rgb(255,255,255)">Roland</span></div>

<div><span style="background-color:rgb(255,255,255)"><br></span></div></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br>