On Wed, Nov 16, 2011 at 6:09 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><div class="gmail_quote">On Wed, Nov 16, 2011 at 00:47, Sean Farley <span dir="ltr"><<a href="mailto:sean@mcs.anl.gov" target="_blank">sean@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">

So, this is basically what I think Barry meant ... except the whole /*R <flags> R*/ part. </blockquote></div><br></div><div>I would want something equivalently verbose because it's HUMAN documentation for how the variables are spelled. Even if the build system is clairvoyant such that it knows what package each header comes from and which variables it needs to link with, a human won't know that and likely won't know where to find out. Spelling out those variables, which they can query through the makefile include, a CMake include, or Python (preferably with the same spelling in each case) makes it understandable.</div>

<div><br></div><div>I don't care about the specifics of the syntax, but I think the variables should be spelled out.</div>
</blockquote></div><br>There is a big difference between<div><br></div><div>  1) Using only the necessary include directories for a given compile, which might work</div><div><br></div><div> and</div><div><br></div><div>  2) Removing includes we "don't need", which I do not think will work</div>
<div><br></div><div>Starting with 1). This will break things like "make getincludedirs", unless you want to maintain one</div><div>thing with the kitchen sink for users, and one tailored thing for PETSc. I think this will generate weird</div>
<div>errors where the full line breaks something, but we never see it because we use the custom build.</div><div>I could still support this if we tested the antique version along with the custom one.</div><div><br></div><div>
However with 2), how would we distinguish includes we only want if the package is found from those</div><div>that just do not work because of a configuration/build bug? If its annonation, as Jed suggests, how is</div><div>
that a step up from #ifdef?</div><div><br></div><div>   Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>
</div>