The missing documentation is addressed in <a href="https://gerrit.gromacs.org/#/c/2172/">https://gerrit.gromacs.org/#/c/2172/</a>. Review will be welcome :-)<div><br></div><div>Mark<br><br><div class="gmail_quote">On Sat, Feb 9, 2013 at 12:02 AM, Mark Abraham <span dir="ltr">&lt;<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</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 class="im">On Fri, Feb 8, 2013 at 9:58 PM, 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 dir="ltr"><div class="gmail_extra"><div><br></div><div class="gmail_quote"><div>On Fri, Feb 8, 2013 at 5:34 PM, Mark Abraham <span dir="ltr">&lt;<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><br><div class="gmail_quote"><div>On Tue, Feb 5, 2013 at 8:58 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Note that I&#39;m not talking about some magic override, but simply the ability to go to the flags and remove e.g. the &quot;-ip&quot; icc flag which I know that it can in some cases cause performance regression.<br>




</div></div></div></div></blockquote></div><div><br>In a fresh release-4-6 build tree, if you use</div><div><br></div><div>CC=icc cmake .. -DGMXC_CFLAGS_RELEASE=&quot;-no-ip&quot;</div><div><br></div><div>you get</div><div>



<br>
</div><div>cd /nethome/mark/git/another-r46/build-cmake-amd2/src/gmxlib &amp;&amp; /opt/intel/composer_xe_2011_sp1.9.293/bin/intel64/icc  -Dgmx_EXPORTS -DTMPI_SET_AFFINITY -DHAVE_CONFIG_H -DHAVE_RDTSCP -DTMPI_EXPORTS -msse2   -std=gnu99 -Wall   -ip -funroll-all-loops -no-ip -O3 -DNDEBUG -fPIC -I/nethome/mark/git/another-r46/build-cmake-amd2/src -I/nethome/mark/git/another-r46/build-cmake-amd2/include -I/nethome/mark/git/another-r46/include -I/nethome/mark/git/another-r46/src/gmxlib   -openmp -o CMakeFiles/gmx.dir/rmpbc.c.o   -c /nethome/mark/git/another-r46/src/gmxlib/rmpbc.c</div>




<div><br></div><div>which seems to do roughly what you want, from a one-shot, because we have partially segmented the sets of flags GROMACS adds, and prepend them for each run of cmake. In this case, GMXC_CFLAGS_RELEASE is the magic name for the C flags we add for the Release build type. Because we prepend the flags to the initial value (which is initially unset by GROMACS), the value passed in from the command line is there at the end. Then, because GROMACS no longer caches the flags we generate, things can be changed later.</div>



</div></blockquote><div><br></div></div><div>Thanks, that indeed seems to be a decent workaround for my very specific example. Unfortunately, this won&#39;t work in general. It will only work if the user wants to remove/inactivate a GROMACS-default compiler flag which happens to have a -no-FOO pair.</div>


</div></div></div></blockquote><div><br></div></div><div>...and works when adding a new flag. What use cases are there that are not</div><div>* inactivating a current flag, or</div><div>* replacing a current flag, or</div>
<div>

* activating a new one?</div><div>Of those, what can&#39;t be solved by generating all the flags and doing a wholesale replacement with GMX_SKIP_DEFAULT_FLAGS?</div><div><br></div><div>The biggest problem I can come up with is needing to remove a flag for which there is no negation option (which itself sounds like a serious defect in a compiler command line syntax, given the prevailing behaviour of gcc and icc as I understand them).</div>
<div class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>It would be good to document this, but as it only works in a corner case I&#39;m not sure it&#39;s worth it.</div><div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div class="gmail_quote">
<div><br></div><div>Note that CMake caches that command-line initial value itself, so that the next call to cmake will also result in -no-ip. Then when you want some other set of flags, without touching the cache you can do</div>




<div><br></div><div>CC=icc cmake .. -DGMXC_CFLAGS_RELEASE=&quot;&quot;</div><div><br></div><div>and this reverts to the out-of-the-box functionality (or you could try a new set of flags if you wanted).</div><div><br></div>




<div>Your original example where -m and -x conflict and lead to warnings is irritating, but not a deal-breaker. Using GMX_SKIP_DEFAULT_CFLAGS provides a two-step approach to fixing that. Obviously, make knows how to tell the compiler the right things to do (e.g. src/buildinfo.h has the full CFLAGS in it), so a *make* target that printed out the CFLAGS (whole and/or in parts) might be a useful thing.</div>



</div></blockquote><div><br></div></div><div>Sure, that&#39;s all clear to me, except that the &quot;two step approach&quot; requires more like 4 steps :)  Additionally it is really easy to screw up for the aforementioned reasons (see  the details on the risk of unknowingly removing -O3).</div>


</div></div></div></blockquote><div><br></div></div><div>You can&#39;t have a one-step solution for modifying default flags without having either</div><div>* a million options for all possible flags (and one of my attempts to fix #1038 was criticised for having too many options - <a href="https://gerrit.gromacs.org/#/c/1908/" target="_blank">https://gerrit.gromacs.org/#/c/1908/</a>)</div>


<div>* knowing in advance what the defaults are</div><div><br></div><div>What&#39;s your fourth step? :-)</div><div>1. cmake ..</div><div>2. Find out what the default flags were - maybe automatically if there&#39;s a way to get cmake to do it usefully</div>


<div>3. cmake .. -DGMX_SKIP_DEFAULT_FLAGS=on -DCMAKE_C_FLAGS=&quot;blah&quot;</div><div>4. Profit???</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_quote"><div>There&#39;s currently no way to say &quot;cmake -DUSE_MY_FLAGS_ONLY_IM_SUPER_SMART=-blahblah&quot;. I&#39;m not philosophically opposed to having one, but since compilers normally act on the last of a series of inconsistent flags, the above approaches seem workable if we document them in an advanced section of the installation guide. I think there are probably more not-competent-enough users who&#39;d wrongly try to use it (or use it wrongly) and run into problems than smart-enough users/admins with a real need case.</div>



</div></blockquote><div><br></div></div><div>That&#39;s exactly why I&#39;m not certain that this workaround is worth documenting. The  problem is that the above approach solves only a special case: </div><div>- will only work for removing a -FOO for which there is a &quot;-no-FOO&quot; *and*</div>



<div>- the compiler used has the policy of silently overriding flags.</div></div></div></div></blockquote><div><br></div></div><div>As I said above, the approach for appending user flags is more general than you have so far recognized. Changing our build system to perhaps support warning-free building for &quot;niche market&quot; build cases seems like a poor return on our time.</div>
<div class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Not only that there is no way to set a &quot;USE_MY_FLAGS_ONLY_IM_SUPER_SMART&quot; variable, but the GMX_SKIP_DEFAULT_CFLAGS workflow is IMO too complicated and fragile (ref:-O3 issue) even for advanced users.</div>


</div></div></div></blockquote><div><br></div></div><div>Even an advanced user has to find out what the flags are before they attempt to modify them. Any procedure that lets them do that is workable. Even just documenting &quot;look at src/buildinfo.h&quot; is technically a solution for finding out the compiler flags.</div>
<div class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_quote"><div><div>Is there anything you want to be able to do that these kinds of workflows do not support?</div></div></div></blockquote><div><br></div></div><div>Uhmm, I guess I should clarify this. I am not trying to solve some burning issue that has suddenly crippled me. All my examples were simply use-cases meant to illustrate real-world scenarios in which the new behavior of the build system causes issues. </div>



<div><br></div><div>So let me state it again: I am trying to discuss usability concerns of our build system that affect the type B users (i.e people familiar with the concept of compiler flags, comipler optimization, CFLAGS, etc).</div>


</div></div></div></blockquote><div><br></div></div><div>Sure, but there&#39;s so far no example of a problem/compiler for which some solution exists using the current mechanisms (if they were documented). Half the exotic compilers people might try are going to perform badly and we&#39;ll tell them to go and use [ig]cc anyway...</div>
<div class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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&#39;s why I find it unfortunate that the build system got crippled in an attempt to fix that issue. Of course, I am biased, but putting aside the fact that I will suffer from this build system &quot;behaviour regression&quot;, I think many sysadmins and other advanced users will also be scratching their heads.<br>




</div></div></div></div></blockquote><div><br></div></div><div>If so, gmx-users must have some filters on it ;-)</div></div></blockquote><div><br></div></div><div>I hope you are not suggesting that:</div><div>&quot;not (exists complaints) =&gt; not (exists issues)&quot;</div>


</div></div></div></blockquote><div><br></div></div><div>No, but if they&#39;re not important enough to write an email about, then they&#39;re not important enough for us to pre-emptively solve.</div><div class="im"><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>GROMACS 4.6 has been out for just a few weeks and I am fairly certain that many have not even gotten as far as installing it.</div></div></div></div></blockquote>


<div><br></div></div><div>OK, but we still aren&#39;t going to prioritize solving non-yet-demonstrated problems over the ones we know about :-)</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Moreover, most of the potential issues do not manifest as a catastrophic failures, but are rather silent.</div></div></div></div></blockquote><div><br>


</div></div><div>Sure, but other than making it easy to see the compiler flags (which you can do with make VERBOSE=1, also) what are you suggesting is a problem we can solve?</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>Additionally, the last few years I&#39;ve had the opportunity to be in touch with sysadmins, programmers/engineers of HPC companies, experienced computational scientists, and similar advanced users and have seen their CMake cache and log files. These quite often showed signs of heavy compiler flag customization. Based on this experience, I can safely state that, this category of users does exists, and they do the kind of things that can be problematic with the new build system. Although they might not be great in numbers, I think I still it is not the best idea to ignore them, right?</div>


</div></div></div></blockquote><div><br></div></div><div>Sure - but if we&#39;re considering something like a monthly patch cycle, if there&#39;s something that&#39;s proven to be fixable, we can fix it.</div><div><br></div>
<div>

We can&#39;t ignore the possibility that your past correspondents were working around our old practice of caching CFLAG variables prematurely, or that they wouldn&#39;t just go for our GMX_SKIP_DEFAULT_CFLAGS solution even if we had something more exotic available.</div>
<div class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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 &quot;mdrun -version&quot; 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&#39;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>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.<br>




</div></div></div></div></blockquote><div><br></div></div><div>CMake printing a summary seems awkward to me. If it&#39;s written as a status message, you can&#39;t see it with ccmake, and if it&#39;s written as a warning ccmake users will get in the habit of skipping real warnings. If using cmake, we&#39;d want logic to only print such summary information for the final iteration - not sure if that&#39;s possible/easy enough to do.</div>



</div></blockquote><div><br></div></div><div>Printing a summary after the first time configuring succeeds should be quite simple do do - that&#39;s how the GPU-related notes are issued when GPUs are detected in the build machine but CUDA is not found.</div>


</div></div></div></blockquote><div><br></div></div><div>Yeah, but that&#39;s not a sound solution if/when we have further configuration that might scroll it off screen, and not a solution at all for ccmake, as above.</div>
<div class="im"><div>

<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_quote"><div>However, a make target to print the configuration seems to address most of the issue. It replaces some of the use cases for inspecting config.log one might have with autoconf build systems. Yes, you&#39;d have to run a normal cmake to find out the default (whether by a CMake summary or this make target I propose), then decide how to modify it, then apply it using some of the above mechanisms. If you magically know already what the defaults will be, you can skip the first stage already and jump straight to using GMX_SKIP_DEFAULT_CFLAGS. What do you think?</div>



</div></blockquote><div><br></div></div><div><div>I&#39;d say we should print a configuration summary (with C/CXX/NVCC flags and the most important other options like fftw, CUDA, etc) both after the configure succeeds the first time as well as on user request.</div>



</div><div><br></div><div>I think a target is a good idea, but I&#39;m wondering whether a target is it more intuitive and/or easier to implement than having a cmake option that the user can turn on to get the summary printed.</div>



<div><br></div><div>To check the configuration on certain build directory which one of the following would you prefer?</div><div><br></div><div>$ make print-config-summary</div><div><br></div>
<div>$ cmake -DGMX_PRINT_CONFIG_SUMMARY</div></div></div></div></blockquote><div><br></div></div><div>The former, because auto-complete will type for me.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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>Fine, remove that step, but you&#39;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></blockquote><div><br></div></div><div>I was turned off by the tone of the original email. I imagine that has something to do with the low response rate so far. We&#39;ve all been wrong at some point. Let&#39;s </div>



</div></blockquote><div><br></div></div><div>I see you criticism and I was indeed a bit pissed in the beginning. Sorry for the rather pushy mail.</div><div><br></div><div>However, I still think that this major change in the build system behavior was merged in without much discussion, review, or feedback. The same is true for the closing of related bugs - if not both, at least 1040.</div>


</div></div></div></blockquote><div><br></div></div><div>#1038 was up for several months. My RFC for fixing it (<a href="https://gerrit.gromacs.org/#/c/1908" target="_blank">https://gerrit.gromacs.org/#/c/1908</a>) was up for a month, and unfortunately you didn&#39;t manage to comment on it. Roland&#39;s solution for #1038 addressed the issue squarely in the context of that lengthy discussion, and passed our normal standards of code review. So I took my original attempt down. No problem there.</div>


<div><br></div><div>#1040 was posted by you and also up for several months. Roland&#39;s solution permits some of the operations you requested (one-shot command lines, and adding a compiler option without cache editing) though we still need to document how/when to use it.</div>


<div><br></div><div>Your other suggestion in #1040 requires us to somehow override CMake&#39;s default behaviour, as noted by Roland there. Changing that would require significant discussion, and it was entirely appropriate not to do that at all. I agree that this behaviour of CMake makes it easy for the user to do the wrong thing, but that is also something we can document. &#39;Fixing&quot; it might leave us vulnerable in the future to some change in CMake&#39;s behaviour. So maybe the Redmine issue was closed prematurely, but the code passed the normal review and addressed the fraction of your bug report that was readily addressable.</div>


<div><br></div><div>These issues are up for months and you didn&#39;t manage to make the time to discuss how to solve them. Others had been discussing and trying to solve them. They thought the issues were solved and acted upon their consensus. So the ball is in your court to show how they are not solved. If you still don&#39;t have time to do that, then they&#39;re still putatively solved :-)</div>
<div class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_quote"><div>start discussions by asking questions like &quot;is there supposed to be a way for a user to add/replace/find out about a compiler flag?&quot; If there isn&#39;t (or it isn&#39;t a </div>
</div></blockquote><div><br></div></div><div>Again, you&#39;re right, I could have been a bit less judgmental. However, as I know our the build system fairly well and I am also somewhat familiar with cmake, I was quite certain that there is no robust workaround the issues raised.</div>


<div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div>good solution) then discussion can move forward happily to solving the problem. If there is an existing solution, people are going to be happier to mention it if they don&#39;t feel like they have to defend their previous actions, or confront the asker by telling them they were wrong :-)</div>



</div></blockquote><div><br></div></div><div>There isn&#39;t much to defend here, I think. This was *a* solution to a/some problem(s) which introduced a set of other problems. My tone and wording was not demanding because it was questioning the solution, but because I was questioning:</div>



<div>i) whether introducing new issues was really appropriate/necessary;</div><div>ii) merging and closing bugs hastily without much feedback.</div></div></div></div></blockquote><div> </div></div><div>Unfortunately, Redmine doesn&#39;t note patches that never hit the history, but to suggest there was only limited discussion is simply wrong.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Mark</div></font></span></div>
</blockquote></div><br></div>