<div dir="ltr"><div class="gmail_extra">On Tue, Feb 5, 2013 at 9:26 PM, Roland Schulz <span dir="ltr"><<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Tue, Feb 5, 2013 at 2:58 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">For all developers out there: RFC.<br>
<br>
I hope you do realize that the issues we are discussing are not if-s and when-s and you'll face them as soon as you want to add/remove/change a compiler flag!<br></div></div></blockquote></div><div>sure. It is even clearly documented in the commit message.</div>
</div></div></div></blockquote><div><br></div><div>Not exactly. The commit message suggests that the new behaviour can give the user "total control". The problem is that because GROMACS and CMake-default flags are treated differently, this is not true and as illustrated before one can end up screwing up performance by not realizing the implications of this.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div></div><div>I'll have a look at the discussion, but I'll need quite some time for that as it very lengthy and contains a long, slightly unrelated, debate.<br>
<br>
</div>
<div>Note that I'm not talking about some magic override, but simply the ability to go to the flags and remove e.g. the "-ip" icc flag which I know that it can in some cases cause performance regression.<br>
</div></div></div></div></div></blockquote></div><div>That's the problem. It is not that easy. I originally made a more complicated suggestion which would have allowed overwrite but it would have been very complicated. So please take the time to read everything AND make a specific suggestion of how to change it. And also keep in mind that we usually don't change behavior after a release.</div>
</div></div></div></blockquote><div><br></div><div>That "AND" is rather demanding. I have raised an issue and the issue is not rendered irrelevant unless I suggest a specific implementation as solution.<br><br></div>
<div>IMHO there isn't much point sticking to a behaviour that causes more trouble than good. So as much as I love that rule a bug requires a fix and this behaviour is, in my opinion, (borderline) buggy. <br></div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<div>
In my eyes, reviewing and changing flags is much more important than the consistency of acceleration flags across cmake reruns, that's why I find it unfortunate that the build system got crippled in an attempt to fix that issue. </div>
</div></div></div></div></blockquote></div><div>That wasn't the only problem. It wasn't consistent at all. </div></div></div></div></blockquote><div><br></div><div>Well, not to start a long flaming, ones easy fix (that would have avoided introducing new issues) would have been as simple as adding the following statement to the docs: "changing CMake variables and re-configuring is only supported for [list of variables], in all other cases remove the cache and re-configure".<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div></div>
<div>and adding or overriding should be possible through a single command-line invocation.<br>
<br>
More concretely IMO what we need is:<br>
- A summary printed or at least some read-only advanced variables so that one does not need to run e.g "mdrun -version" to know what flags are used;<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div>I was (and still am) all for the summary. I really liked Teemu's start of it. But it got cut because of time. Not sure it would be a good idea to print just the flags without having a full summary. I think having read-only variables is very confusing.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div></div><div class="im"><div>I see your point, but you have yet to reply to my criticism on the fact that
<i>it is impossible to at least check what flags are being used</i> and that is a major flaw.</div></div></div></div></div></div></blockquote><div>Like I said I was hoping for the summary. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>
- An intuitive and consistent way to add/change the flags, what the user wants is simple, but currently requires a set of strange steps: enable skipping GROMACS flags, copy the printed flags, remove cache, re-run cmake with the copied flags.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div>No need to remove the cache.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div></div><div class="im"><div>Fine, remove that step, but you've to add two more instead:<br>
- check default CMake flags;<br>
- re-add those when setting flags manually<br>
</div>
<div><br>
</div>
<div>Again, I would very much appreciate of you or others developers would actually comment on the issue in question: the usability concerns around this rather long, complicated, and error-prone set of steps required just to change a flag -Foo to -Bar.<br>
</div></div></div></div></div></div></blockquote><div>Please not that it is still better than some other compiler/linker flags which can't be changed at all. E.g. OpenMP flags are autodected and can't be changed at all (unless you change the cmakelists code). The </div>
</div></div></div></blockquote><div><br></div><div>AFAIK the OpenMP flag was easy to change before the upstream merge (by just editing the CMAKE_C_FLAGS), not sure where did it get complicated. Moreover, that's not a great example as if the flag check passes, the OpenMP flag will most probably be correct so there isn't much point in changing it.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>same is true for any linker flags (e.g. bug 911). To repeat myself: I would have liked to have a solution which would have made overwriting easy and which would have contained a summary. But that was the solution which seemed best with the available time. Please also note that these bugs are 3 months old. Everyone had plenty of time to come up with a better solution in those 3 months.</div>
</div></div></div></blockquote><div><br>Here's some nitpicking for the sake of correctness: #1040 was <2 months old when it got closed (Nov 20 - Jan 10) without ever getting feedback (was not even requested); moreover the change set that claimed to fix it was not reviewed properly either. Therefore this major change in build system behaviour could not be, and probably is still not obvious to most developers - that's why I started the discussion.<br>
<br>Lastly, let's not treat the issue in a way which implies that just because nobody had a better implementation at hand - and unfortunately even the discussion was very limited, I have to admit -, the current solution should be treated as something that everybody knows of - including its drawbacks and general implications -, accepts, and should avoid criticizing. That's especially the case as neither installation guide nor any advanced wiki page or documentation (at least not that Google knows of: <a href="http://goo.gl/JBokD">http://goo.gl/JBokD</a>) describes step-by-step the rather complicated and fragile process of changing compiler flags.<br>
<br></div><div><br></div><div>Cheers,<br></div><div>Szilard<br></div><div></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>Roland</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<br>
</div>
<div>Cheers,<span class=""><font color="#888888"><br>
<div>--<br>
Szilárd</div>
<br>
</font></span></div><div><div class="h5"><div><div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Roland</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div>
<div>It might be a good idea to override everything or nothing regardless whether it's GROMACS or CMake flags.<br>
<br>
</div>
<div>Cheers,<br>
Szilard<br>
</div>
<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Roland </div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">Cheers,</div>
<span><font color="#888888"><span><font color="#888888">
<div>
<div>--<br>
Szilárd</div>
</div>
</font></span></font></span></div>
<span><font color="#888888"></font></span></div>
<span><font color="#888888"></font></span></blockquote>
</div>
<div><span><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">
cmb.ornl.gov</a><br>
<a href="tel:865-241-1537" value="+18652411537" target="_blank">865-241-1537</a>, ORNL PO BOX 2008 MS6309
</font></span></div>
</div>
</div>
<br>
</div>
<div><span><font color="#888888">--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">
gmx-developers-request@gromacs.org</a>.<br>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div>
<div><br>
</div>
-- <br>
ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">
cmb.ornl.gov</a><br>
<a href="tel:865-241-1537" value="+18652411537" target="_blank">865-241-1537</a>, ORNL PO BOX 2008 MS6309 </div>
</div>
</div>
<br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote>
</div></div></div></div></div>
<br>
</div>
</div>
</div>
</blockquote></div><div><div class="h5"><br><br clear="all"><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309
</div></div></div></div>
<br>--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br></div></div>