Request related to SLEPc

Matthew Knepley knepley at gmail.com
Fri Dec 12 10:46:34 CST 2008


On Fri, Dec 12, 2008 at 9:32 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:

> I would like to add that, despite the new buildsystem if by far better
> than the old one, PETSc has lost a nice feature of being able of being
> installed in a central location for multiple $PETSC_ARCH's . This
> feature is something I need, as I have to maintain the PETSc
> intallation in our cluster, and I really need to have at least debug
> and optimized builds because our applications can also be built in the
> two modes.


I do not understand the problem. Here we follow the Linux install model. If
you
want different versions, they are just in different directories.

  Matt


>
> Up to now, I'm using this rule: I pass to configure
> --prefix=/usr/local/petsc/3.0.0/$PETSC_ARCH. But then, after
> installation, the actual $PETSC_DIR should be passed something like
> this: /usr/local/petsc/3.0.0/linux-gnu. In petsc4py I've tried to be
> smart: it can build against the build directory, against an standard
> install (I mean, when you pass --prefix=/path/to/petsc) or my special
> rule (--prefix=/path/to/petsc/$PETSC_ARCH). Moreover, petsc4py can be
> built against MANY different $PETSC_ARCH's, this way, before running
> an script, you just setenv PETSC_ARCH=some-arch, and the Python import
> machinery will internally load the appropriate extension module. This
> is really, really nice, as I can run a small problem with debug libs,
> and next run to a larger problem with optimized libs, with just
> exporting an environmental variable.
>
> When using the PETSc makefiles for other C/C++ apps, my special
> install rule will not work the same than when building against the
> PETSc build directory. Of course, I believe it should be easy to make
> it work, but I'm thinking that many other users will run in the same
> need.
>
>
> Now, regarding the specific cuestions of Jose, I've noticed that the
> header "petscconf.h" has a line #define PETSC_ARCH_NAME "XXX". I
> cannot figure out how this define is generated (autoconf stuff?), but
> if this define is guaranteed to be the same as the $PETSC_ARCH used to
> build PETSc, then Jose perhaps could use a regex to look for a
> meaningfull $PETSC_ARCH value.
>
>
> On Fri, Dec 12, 2008 at 1:01 PM, Jose E. Roman <jroman at dsic.upv.es> wrote:
> > SLEPc's configure.py uses the value of $PETSC_ARCH in order to setup
> > everything for installation. We never had a $SLEPC_ARCH variable because
> our
> > configure.py does not add platform-dependent functionality.
> >
> > Now the problem comes when PETSc has been configured with --prefix and
> > installed with make install. In that case, $PETSC_ARCH is no longer
> > available and SLEPc's configure.py is in trouble.
> >
> > A simple workaround would be that PETSc's configure (or make install)
> would
> > add a variable (e.g. PETSC_ARCH_NAME) in file petscvariables. We parse
> this
> > file so the arch name would be readily available even if $PETSC_ARCH is
> > undefined.
> >
> > Can someone do this? Other solutions are welcome.
> >
> > Thanks,
> > Jose
> >
> >
>
>
>
> --
> Lisandro Dalcín
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>
>


-- 
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/20081212/2187efb8/attachment.html>


More information about the petsc-dev mailing list