Why did you removed PETSC_ARCH_NAME variable in makefiles?

[Matthew Knepley]

On Fri, Nov 27, 2009 at 1:45 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:

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

IIUC? I do not text.

I would say even bitwise comparison of the pickle is fine. If it changes,
you need
to reconfigure PETSc, and that means reconfiguring SLEPc.

  Matt


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



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091127/a9f4543d/attachment.html>