On Fri, Dec 12, 2008 at 9:32 AM, Lisandro Dalcin <span dir="ltr"><<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I would like to add that, despite the new buildsystem if by far better<br>
than the old one, PETSc has lost a nice feature of being able of being<br>
installed in a central location for multiple $PETSC_ARCH's . This<br>
feature is something I need, as I have to maintain the PETSc<br>
intallation in our cluster, and I really need to have at least debug<br>
and optimized builds because our applications can also be built in the<br>
two modes.</blockquote><div><br>I do not understand the problem. Here we follow the Linux install model. If you<br>want different versions, they are just in different directories.<br><br>  Matt<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Up to now, I'm using this rule: I pass to configure<br>
--prefix=/usr/local/petsc/3.0.0/$PETSC_ARCH. But then, after<br>
installation, the actual $PETSC_DIR should be passed something like<br>
this: /usr/local/petsc/3.0.0/linux-gnu. In petsc4py I've tried to be<br>
smart: it can build against the build directory, against an standard<br>
install (I mean, when you pass --prefix=/path/to/petsc) or my special<br>
rule (--prefix=/path/to/petsc/$PETSC_ARCH). Moreover, petsc4py can be<br>
built against MANY different $PETSC_ARCH's, this way, before running<br>
an script, you just setenv PETSC_ARCH=some-arch, and the Python import<br>
machinery will internally load the appropriate extension module. This<br>
is really, really nice, as I can run a small problem with debug libs,<br>
and next run to a larger problem with optimized libs, with just<br>
exporting an environmental variable.<br>
<br>
When using the PETSc makefiles for other C/C++ apps, my special<br>
install rule will not work the same than when building against the<br>
PETSc build directory. Of course, I believe it should be easy to make<br>
it work, but I'm thinking that many other users will run in the same<br>
need.<br>
<br>
<br>
Now, regarding the specific cuestions of Jose, I've noticed that the<br>
header "petscconf.h" has a line #define PETSC_ARCH_NAME "XXX". I<br>
cannot figure out how this define is generated (autoconf stuff?), but<br>
if this define is guaranteed to be the same as the $PETSC_ARCH used to<br>
build PETSc, then Jose perhaps could use a regex to look for a<br>
meaningfull $PETSC_ARCH value.<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
On Fri, Dec 12, 2008 at 1:01 PM, Jose E. Roman <<a href="mailto:jroman@dsic.upv.es">jroman@dsic.upv.es</a>> wrote:<br>
> SLEPc's configure.py uses the value of $PETSC_ARCH in order to setup<br>
> everything for installation. We never had a $SLEPC_ARCH variable because our<br>
> configure.py does not add platform-dependent functionality.<br>
><br>
> Now the problem comes when PETSc has been configured with --prefix and<br>
> installed with make install. In that case, $PETSC_ARCH is no longer<br>
> available and SLEPc's configure.py is in trouble.<br>
><br>
> A simple workaround would be that PETSc's configure (or make install) would<br>
> add a variable (e.g. PETSC_ARCH_NAME) in file petscvariables. We parse this<br>
> file so the arch name would be readily available even if $PETSC_ARCH is<br>
> undefined.<br>
><br>
> Can someone do this? Other solutions are welcome.<br>
><br>
> Thanks,<br>
> Jose<br>
><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Lisandro Dalcín<br>
---------------<br>
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
Tel/Fax: +54-(0)342-451.1594<br>
<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>