<div class="gmail_quote">On Mon, Mar 21, 2011 at 21:57, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@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 id=":39">We originally started with multiple libraries because in the 1990's PETSc libraries were "BIG" and made live hard for some filesystems and linkers. Now libpetsc.a is not big, by modern standards of big so is there any reason at all to keep the option of having lots of libraries (that don't get tested properly)?<br>
</div></blockquote></div><br><div>I still test that option, but only because I'm paranoid about developing cycles in the dependencies between different packages within petsc. If there was another way to perform this sanity check, I would be fully in favor of getting rid of the option. I'm probably in favor of it regardless.</div>
<div><br></div><div>On my machine, an optimized C libpetsc.so is between 5 and 10 MB depending on optimization flags. A debug C++ with Sieve is a bit over 100 MiB. That 100 MiB is significant on a low-memory platform, but on a low-memory machine, you would expect to link statically and then you only need lots of memory on the development machine.</div>