Why did you removed PETSC_ARCH_NAME variable in makefiles?
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
Why did you removed PETSC_ARCH_NAME variable in makefiles?
Why not just hash the RDict.db?
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
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091127/5095cfbc/attachment.html
Why did you removed PETSC_ARCH_NAME variable in makefiles?
On Fri, 27 Nov 2009, Barry Smith wrote: 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). The issue is not what the prefix model dictates. The issue is: do slepc/petsc4py support both modes of install similar to PETSc. If not why does PETSc need PETSC_ARCH for a prefix install? [if we are so pure with supporting gnu/autoconf model?]. Satish
Why did you removed PETSC_ARCH_NAME variable in makefiles?
On Fri, 27 Nov 2009, Satish Balay wrote: On Fri, 27 Nov 2009, Barry Smith wrote: 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). The issue is not what the prefix model dictates. The issue is: do slepc/petsc4py support both modes of install similar to PETSc. If not why does PETSc need PETSC_ARCH for a prefix install? [if we are so pure with supporting gnu/autoconf model?]. I read the comment slightly out of context - please ignore.. [now I see you are refering to the unique-identifier as a sanity check issue] satish
Why did you removed PETSC_ARCH_NAME variable in makefiles?
On Fri, Nov 27, 2009 at 8:52 PM, Satish Balay balay at mcs.anl.gov wrote: On Fri, 27 Nov 2009, Satish Balay wrote: On Fri, 27 Nov 2009, Barry Smith wrote: ? ?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). The issue is not what the prefix model dictates. The issue is: do slepc/petsc4py support both modes of install similar to PETSc. If not why does PETSc need PETSC_ARCH for a prefix install? [if we are so pure with supporting gnu/autoconf model?]. I read the comment slightly out of context - please ignore.. [now I see you are refering to the unique-identifier as a sanity check issue] Indeed. Right now I've already pushed fixes for the changes in petsc-dev. Currently I can suport a prefix-PETSc+prefix-SLEPc, or non-prefix-PETSc+non-prefix-SLEPc. The later is a non-issue, as PETSC_ARCH more or less disambiguate incompatible builds and moreover let runtime-selection of what variant to use (think of hacking Python import path, though I did something a safer). However, mixes schemes are harder to deal. You know how easy is for end users (and the many naive sysadmins) out there to make nasty mixups of incompatible stuff. I want to protect from that, because I do not want to waste my time with mails arriving at my inbox saying hey Lisandro, I've installed petsc4py and slepc4py, but i get Segmentation fault, do you know what could be going on? This tread got long enough. Let's stop here, please. All us have more important matters to spend our time. I think I'll end-up requiring users to prefix-installs for both PETSc and SLEPc, or non-prefix also for both, but never a mix. -- 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
Why did you removed PETSC_ARCH_NAME variable in makefiles?
On Nov 27, 2009, at 6:04 PM, Lisandro Dalcin wrote: On Fri, Nov 27, 2009 at 8:52 PM, Satish Balay balay at mcs.anl.gov wrote: On Fri, 27 Nov 2009, Satish Balay wrote: This tread got long enough. Let's stop here, please. All us have more important matters to spend our time. I think I'll end-up requiring users to prefix-installs for both PETSc and SLEPc, or non-prefix also for both, but never a mix. Sounds reasonable to me. Having one with prefix and one without is perverse. 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
