Why did you removed PETSC_ARCH_NAME variable in makefiles?

Lisandro Dalcin dalcinl at gmail.com
Fri Nov 27 13:24:19 CST 2009


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.

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



More information about the petsc-dev mailing list