Works now. However, the Scq options do not seem to be tested.<br><br>  Matt<br><br><div class="gmail_quote">On Thu, Jun 11, 2009 at 6:51 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Are there ever any tests of this shit? It broke IMMEDIATELY on my box.<br><br>  Matt<div><div>
</div><div class="h5"><br><br><div class="gmail_quote">On Wed, Jun 10, 2009 at 11:02 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>On Wed, 10 Jun 2009, Barry Smith wrote:<br>
<br>
><br>
>   All petsc-dev users. Next time you pull petsc-dev make sure you pull<br>
> config/BuildSystem also and rerun your configure with<br>
> ${PETSC_ARCH}/conf/reconfigure-${PETSC_ARCH}.py<br>
> As always, report any problems to <a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a><br>
><br>
>   Barry<br>
><br>
><br>
> What I changed. I discovered the ar flags Sq that are much faster than our<br>
> current use of r. For my laptop these are the timings for "make all" debug<br>
> version<br>
><br>
>                regular libraries           --with-single-library(new<br>
> config/configure.py option to put all code into libpetsc.a (not yet working<br>
> for shared libraries)).<br>
><br>
> old           9 min 23 sec                    28 min<br>
> new         2 min 49 sec                      2 min 58 sec<br>
<br>
</div>On linux [my laptop] - both the old and new mode [regular libraries]<br>
take about 2min10sec.<br>
<div><br>
><br>
> What I changed: added the flag FAST_AR_FLAGS that is used by libfast: instead<br>
> of AR_FLAGS; also added fast versions of buildmod called buildmodfast that use<br>
> libffast that uses FAST_AR_FLAGS<br>
><br>
> Once we get rid of the damn make we should see the entire "make all" take less<br>
> than a minute<br>
<br>
</div>The issue is the recursive make - and all the shell processes that get<br>
created during it. If we have something eqivalent to automake - then<br>
it should zip through everything with 'make -j 8' - on the newer<br>
multicore machines pretty quickly..<br>
<font color="#888888"><br>
Satish<br>
</font></blockquote></div><br><br clear="all"><br></div></div><font color="#888888">-- <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>

</font></blockquote></div><br><br clear="all"><br>-- <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>