Why did you removed PETSC_ARCH_NAME variable in makefiles?

[Barry Smith]

On Nov 27, 2009, at 1:24 PM, Lisandro Dalcin wrote:

> On Fri, Nov 27, 2009 at 2:21 AM, Satish Balay <balay at mcs.anl.gov>  
> wrote:
>>
>> The way I look at it - the primary complexity here is from PETSc
>> buildsystem.
>>
>> Because PETSc buildsystem supports both types of builds - 'prefix'  
>> and
>> 'regular' - one is forced to use PETSC_ARCH 'during build process' -
>> even with a prefix build [even though it doesn't make any sense to
>> this gnu build model].
>>
>> Once we force this on users - I don't think we are justified in
>> removing traces of this intermediate step - if slepc/petsc4py would
>> like to use info.
>>
>
> Indeed. SLEPc/TAO and {petsc|slepc|tao}4py are not normal "users" of  
> PETSc.
>
>> To me - it makes perfect sense for these packages to mimick both the
>> PETSc build modes as closly as possible [both modes]. So if they need
>> PETSC_ARCH used during PETSc build - then thats fine.  Perhaps it
>> should be named PETSC_ARCH_value_used_at_build_time - or a more
>> descriptive name to satisfy Barry's concerns.
>>
>
> The whole point of my concerns is that I need to have some sort of
> "unique-identifier" that let me know a SLEPc build match a PETSc
> build. For non-prefix builds of PETSc and SLEPc, that is PETSC_ARCH.
> For prefix installs, I've somewhat lost my way to make sure PETSc and
> SLEPc builds match each other.

     How does the gnu/autoconf world handle this. If you have two gnu/ 
autoconf installed packages how can you tell they are compatible? You  
should use the same type of mechanism they use.  (what?, they don't  
have such a mechanism? Well then that is a limitation of the --prefix  
model and you have to live with that).

    Barry
>
> Could we devise a way to generate a Makefile variable embeding some
> info from the most basic configuration setup, for example a string
> with coma-separated key:value pairs, something like,
>
> PETSC_CONF =  
> "platform:linux2,arch:i686,compiler:gnu,language:c,debug:no,integer: 
> 32bit,scalar:real,precision:double"
>
> and any other important bit I could be missing?
>
> This way, SLEPc's configure could get the value from parsing PETSc
> makefiles, and then SLEPc could save that value in its own makefiles.
> Then petsc4py/slepc4py could use that info (at build time and runtime)
> to have some sort of assurance that libraries from the PETSc build and
> the SLEPc build are more or less compatible, and can be used together.
> You know, errors should never pass silently :-)
>
> What do you think?
>
>
> -- 
> 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