<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 1, 2017 at 12:31 AM, Eric Irrgang <span dir="ltr"><<a href="mailto:ericirrgang@gmail.com" target="_blank">ericirrgang@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div><div> * can/should Gerrit and Jenkins handle git submodules</div><div> and be configured to `git pull --recurse-submodules`</div><div> so that we don't have to include potentially useful supporting</div><div> libraries in draft commits?</div></div></div></blockquote><div><br></div><div>This far we haven't, and I don't think we should. To the extent that we can use optional libraries, the detection of such libraries on the system (and being able to disable them) is an important part of the configuration (which should be tested) rather than always building them ourselves. Linux distributions are also picky that they don't want us to bundle a library on Gromacs, but we should use the system packaged version.</div><div><br></div><div>Be warned that we are restrictive even with optional libraries, and exceptionally restrictive with hard dependencies - mostly because we've repeatedly seen that people are happy to add them, but then they don't do the work of supporting it when there are problems - and finally we have to kill them a few years later. The first requirement is that it should be tested on all normal platforms (including Windows & OSX) and that there is a collective will to support it.</div><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><div> * Is there a Gromacs convention for dealing with unused</div><div> parameters in polymorphic methods to avoid compiler warnings</div><div> and potential waste?</div></div></div></blockquote><div><br></div><div>"gmx_unused" is available, but don't go overboard with it. If you start to need it for more than a single parameters the method/class should probably be split into something simpler instead.</div><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><div><br></div><div> * is there a way to keep uncrustify from wanting to mangle brace</div></div><div> construction in constructor initializer lists? e.g. uncrustify wants</div><div> to do this:</div><div><div>MyClass() :</div><div> a_ {nullptr},</div><div>b_ {},</div><div>c_ {</div><div> &b_</div><div>},</div></div><div>...</div></div></blockquote><div><br></div><div>I don't think it should if you use the patched version by Roland - there are quite a few initializer constructs in the source where everything is on one line.</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">--<div>Erik Lindahl <<a href="mailto:erik.lindahl@gmail.com" target="_blank">erik.lindahl@gmail.com</a>></div><div>Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div>
</div></div>