<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 4, 2014 at 12:15 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*******************************************************************************<br>
         UNABLE to CONFIGURE with GIVEN OPTIONS    (see configure.log for details):<br>
-------------------------------------------------------------------------------<br>
Must give a default value for known-mpi-shared-libraries since executables cannot be run<br>
*******************************************************************************<br>
<br>
<br>
Matt, is there something consistent and maintainable that we could do so<br>
that all the checks for issues like this run immediately, before<br>
compilation tests, so that users can get error messages in a reasonable<br>
amount of time?  Few things are more frustrating than waiting so long to<br>
get a trivial error message, then start the entire process over again.<br></blockquote><div><br></div><div>Configure is run in two passes. First we run</div><div><br></div><div>  setupDependencies()</div><div><br></div><div>
for all nodes, and the we run</div><div><br></div><div>  configure()</div><div><br></div><div>in  topological order on the DAG. Checks which do not depend on dependencies can all</div><div>be run in the setupDependencies(). I am going to move all the downloads</div>
<div>here, which will catch errors quickly, and also allow us to asynchronously</div><div>download while other tests run,</div><div><br></div><div>Can you put your check there. Perhaps we should rename the call. It was</div>
<div>originally just for setting up the DAG.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And/or, what about caching results so that re-running after adding this<br>
flag would be fast?  (It scares me too, but I consider configure time to<br>
be a major usability issue.)<br>
</blockquote></div><br>Definitely not.</div><div class="gmail_extra"><br></div><div class="gmail_extra">   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
</div></div>