<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 9, 2013 at 11:57 AM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":9up">Fortunately, b) can be checked easily with 'style checkers', keeping the lifetime of such a bug below 1 day.</div>
</blockquote><div><br></div><div style>That is true, and if we did pull requests (instead of pushing directly), the CI server would do the style checking before it reached the stable branch.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":9up"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To convert this to usual C semantics, we could use (yet another) macro trick<br>
</blockquote>
<br></div>
Replacing CPP with CPP to get rid of CPP? That does not sound like a good approach :-D</div></blockquote><div><br></div><div style>It's CPP, but not conditional compilation. There's a big difference for static code analysis. As we've discussed before, there are certain bits of CPP that we can't remove (without huge refactoring and increased verbosity or adding our own preprocessor, which would be gross and we'd still have to teach the "manipulator" the semantics of that preprocessor). It is not so hard to teach the manipulator about one "safe" macro that gets configuration information. (It can reason about it as if the expression was a const global variable.)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":9up"><div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With this sort of thing, we could write<br>
<br>
if (PETSC_HAVE_(SOMETHING)) {<br>
   some_func(no_headache);<br>
} else { ... }<br>
<br>
which can be reasoned about using normal C semantics. The condition<br>
evaluates at compile time so the code produced (with any optimization)<br>
is identical. If different functions are called in the two cases, the<br>
linker may request both of them. (This can be good or bad.)<br>
</blockquote>
<br></div>
Since #if defined(...) is often used to conditionally enable calls to external libraries, this would require us to either disallow all direct calls to external libraries in all of PETSc core (and use some sublibrary-type generic interface instead),</div>
</blockquote><div><br></div><div style>We do this now by putting that stuff in impls/external-thing/ which is conditionally compiled using #requirespackage in the makefile. We have one access point to that functionality: registration of the corresponding XXCreate_YY(), which is done in XXRegisterAll(). The body of that routine must either use conditional compilation via CPP or be generated using some other tool. CPP is perfectly sufficient for "generating" that file.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":9up"> or to always link against all libraries. The latter is a nightmare with respect to support-requests to petsc-maint.<br>
</div></blockquote></div><br>This is crazy.</div></div>