pull config/BuildSystem and rerun config/configure.py

[Matthew Knepley]

On Thu, Jun 11, 2009 at 10:55 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Jun 11, 2009, at 7:27 AM, Matthew Knepley wrote:
>
>  Works now.
>>
>
>   What was wrong with it?
>

Evidently, bad merge here.


>  However, the Scq options do not seem to be tested.
>>
>
>    Correct. You can add a test for them if you like, I couldn't be
> bothered.


It will happen. It will involve refactoring the AR test.

  Matt


>
>   Barry
>
>
>
>>  Matt
>>
>> On Thu, Jun 11, 2009 at 6:51 AM, Matthew Knepley <knepley at gmail.com>
>> wrote:
>> Are there ever any tests of this shit? It broke IMMEDIATELY on my box.
>>
>>  Matt
>>
>>
>> On Wed, Jun 10, 2009 at 11:02 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>> On Wed, 10 Jun 2009, Barry Smith wrote:
>>
>> >
>> >   All petsc-dev users. Next time you pull petsc-dev make sure you pull
>> > config/BuildSystem also and rerun your configure with
>> > ${PETSC_ARCH}/conf/reconfigure-${PETSC_ARCH}.py
>> > As always, report any problems to petsc-dev at mcs.anl.gov
>> >
>> >   Barry
>> >
>> >
>> > What I changed. I discovered the ar flags Sq that are much faster than
>> our
>> > current use of r. For my laptop these are the timings for "make all"
>> debug
>> > version
>> >
>> >                regular libraries           --with-single-library(new
>> > config/configure.py option to put all code into libpetsc.a (not yet
>> working
>> > for shared libraries)).
>> >
>> > old           9 min 23 sec                    28 min
>> > new         2 min 49 sec                      2 min 58 sec
>>
>> On linux [my laptop] - both the old and new mode [regular libraries]
>> take about 2min10sec.
>>
>> >
>> > What I changed: added the flag FAST_AR_FLAGS that is used by libfast:
>> instead
>> > of AR_FLAGS; also added fast versions of buildmod called buildmodfast
>> that use
>> > libffast that uses FAST_AR_FLAGS
>> >
>> > Once we get rid of the damn make we should see the entire "make all"
>> take less
>> > than a minute
>>
>> The issue is the recursive make - and all the shell processes that get
>> created during it. If we have something eqivalent to automake - then
>> it should zip through everything with 'make -j 8' - on the newer
>> multicore machines pretty quickly..
>>
>> Satish
>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090611/a337860a/attachment.html>