Why did you removed PETSC_ARCH_NAME variable in makefiles?

[Lisandro Dalcin]

On Fri, Nov 27, 2009 at 4:33 PM, Matthew Knepley <knepley at gmail.com> wrote:
>
> Why not just hash the RDict.db?
>

Could work, though it could be a bit too much. For example, would the
hash remains the same after rebuild and reinstall a PETSc
patch-release? IIUC, there should be no need to rebuild and reinstall
SLEPc after a patch-release upgrade of PETSc.


>   Matt
>
> On Fri, Nov 27, 2009 at 1:24 PM, Lisandro Dalcin <dalcinl at gmail.com> 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.
>>
>> 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
>
>
>
> --
> 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
>



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