<div dir="ltr">On Tue, Oct 29, 2013 at 4:02 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><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">Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> writes:<br>
<br>
> On Tue, 29 Oct 2013, Jed Brown wrote:<br>
><br>
>> Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> writes:<br>
>> > If you look at the current configure.log - its after fortran compiler<br>
>> > detection.<br>
>> ><br>
>> > Currently the dependencies [for PETSC_ARCH] are:<br>
>> ><br>
>> >     self.petscdir = framework.require('PETSc.utilities.petscdir', self)<br>
>> >     self.languages = framework.require('PETSc.utilities.languages', self)<br>
>> >     self.compilerFlags = framework.require('config.compilerFlags', self)<br>
>> ><br>
>> > so it need to get that far before PETSC_ARCH can be set/used..<br>
>><br>
>> Okay, but why does it have to go that far?<br>
><br>
> Because of the current dependency "config.compilerFlags -> config.setCompilers"<br>
> The following change moves the arch.py usage up earlier. If configureInstallationMethod()<br>
> can be moved out of petscdir.py - then it can probably move even earlier..<br>
<br>
</div>Matt is the one with vision about BuildSystem dependencies so I'll leave<br>
it to him to comment.</blockquote><div><br></div><div>I see fooling with dependencies as a good thing in general to simplify things, but having not</div><div>much to do with what Jed wants. We can easily buffer till kingdom come.</div>
<div><br></div><div>What needs to be done is to overload write() for the logger, so that if no file is open it buffers,</div><div>and then when a file is set, the contents get dumped in.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> Ideally the buffered stuff for configure.log should be only a few<br>
> lines - without any signigicant tests before it..<br>
<br>
</div>Yeah, so that if it fails, the error message will be short enough that<br>
people can copy and paste it.<br>
<div class="im"><br>
> BTW: there is also etags/fortranstub stuff that configure does - that<br>
> can cause problems with simultaneous builds. So they should be done<br>
> with some locking scheme?<br>
<br>
</div>No locking, just commit the results atomically.  That means write a<br>
temporary file and rename it to replace the existing file.  (Or checksum<br>
and just delete the tmp file if they match, so that modification times<br>
don't change.)<br>
</blockquote></div><br>This is not good enough for the stubs.</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>