On Tue, Nov 15, 2011 at 6:30 PM, 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 Tue, Nov 15, 2011 at 18:18, 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">

<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think this is a wholly bad idea. Putting build logic down in individual makefiles is bad.</blockquote>


<div><br></div></div><div>Why should every object file be built with -I${VALGRIND_INCLUDE}? Why can't just the valgrind sources be compiled with the valgrind flags?</div></blockquote></div><br></div><div>I agree. Including all the dependent libraries is more fragile. We use MPI in our public interface (this is a good thing), so it's okay to include mpi.h. All the other headers should not be in the public interface. Note that this is also important so that they can link with -lpetsc instead of needing -lpetsc -lvarious -lother -llibs-that-are-different-for-each-configuration.</div>

</blockquote></div><br>Yes, but you are advocating a really shitty infrastructure for doing this. How do you expose these when the user turns out to want<div>them (like ParMetis for instance)? How do you follow the chain back to find a bug if you have build logic scattered all over?</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>