On Nov 25, 2009, at 1:03 PM, Lisandro Dalcin wrote:

On Wed, Nov 25, 2009 at 3:19 PM, Barry Smith <[email protected]> wrote:

...

Lisandro,

That change will certainly NOT be reverted. PETSC_ARCH_NAME! what the heck kind of variable name is that?

I agree the name could be messy or misleading.

It is confusing because then PETSc has a PETSC_ARCH and a PETSC_ARCH_NAME variable and having two very similar names with related or identical functionality adds unneeded complexity. The whole point of --prefix is to eliminate the need for and concept of PETSC_ARCH, so to have it still be there (in that you need PETSC_ARCH_NAME) is bizarre and confusing.

But so is PETSC_ARCH, which should actually be something like PETSC_CONF, right?

...

I need to understand the reason for PETSC_ARCH_NAME, then we can come up with some solution.

OK. Let see.

...

What is the difference between PETSC_ARCH_NAME and PETSC_ARCH?

None

...

Is it only needed when --prefix is used (so PETSC_ARCH does not exist),

Yes.

...

if so, exactly why is it needed, the whole idea behind --prefix is to eliminate PETSC_ARCH,

In the particular case of petsc4py, the Python extension module get's installed as "lib/$PETSC_ARCH/PETSc.so". Then, for --prefix installs of PETSc, I use the PETSC_ARCH_NAME (obtained from parsing makefiles, as for many other configuration stuff).

...

so why is it needed? How is PETSC_ARCH_NAME used?

I can certainly change my way of doing things in petsc4py. Perhaps I should install as "lib/PETSc.so" for --prefix PETSc builds?

Absolutely, the PETSC_ARCH should NOT be in the path there. By keeping the $PETSC_ARCH around when using the --prefix you are totally abusing the whole concept of --prefix and have some weird half-assed creature that is not really traditional PETSc or --prefix style. You are doing the --prefix stuff wrong (see my note below).

I said this before, but let's go one more time: I find --prefix installs of PETSc a bit useless for general-purpose installations. Supose as sysadmin "make install" PETSc in a cluster. She likely built using a C as language, double precision real scalars, 32bit integers, (dbg/opt?). Such configuration does not fit all applications. Some users may require C++, other may want complex, others may want to run her own codes with a debug version. Then I see VERY little point on --prefix builds of PETSc. Moreover, in our machines at CIMEC I maintain central installations of PETSc at /usr/local/petsc/3.0.0. This is not done at all with --prefix and "make install", instead, "/usr/local/petsc/3.0.0" is a HG clone of release-3.0.0.

For all these reasons, petsc4py stills support clearly separated lib/$PETSC_ARCH/PETSc.so ext modules. For example, switching from debug to optimized is just a matter of "export PETSC_ARCH=opt-arch-name" and "python script.py". Perhaps now it is the time to change a bit this, but I certainly need some advice/discussion/comments from your side.

I do agree with your about --prefix. It is pandering to the crowd of "how gnu does things is the best and only way things should ever be done and if you don't do it that way then you are a complete idiot" school. But the reason we support it is that its is very commonly asked for and EXPECTED by many, many people. It is a hopeless cause to convince these people that our model is better. I ignored this crowd for many, many years but finally broke down and figured out a fairly reasonable (though perhaps not perfect) way of doing it the "gnu way" also so the many people who live and die with the "./configure -- prefix; make ; make install" are happy and can just do their approach (even though it is a silly and bad model). So basically I am asking you and Jose to support the traditional PETSc approach and the pure --prefix approach and not have some intermediate thing that does not fully follow the GNU --prefix model. Barry

-- 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