Why did you removed PETSC_ARCH_NAME variable in makefiles?

[Barry Smith]

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

> On Wed, Nov 25, 2009 at 3:19 PM, Barry Smith <bsmith at mcs.anl.gov>  
> 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