Why did you removed PETSC_ARCH_NAME variable in makefiles?
I have made some changes so that when using the --prefix option there is no need to set PETSC_DIR or PETSC_ARCH. ./configure --prefix=... other options make make install Barry On Nov 27, 2009, at 5:47 PM, 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?]. Satish
Why did you removed PETSC_ARCH_NAME variable in makefiles?
On Sun, Nov 29, 2009 at 7:55 PM, Barry Smith bsmith at mcs.anl.gov wrote: ?I have made some changes so that when using the --prefix option there is no need to set PETSC_DIR or PETSC_ARCH. ./configure --prefix=... ? other options make make install Great! Many thanks, Barry! Jose: Any chance you can implement something similar in SLEPc? -- 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 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
Why did you removed PETSC_ARCH_NAME variable in makefiles?
On 25/11/2009, Barry Smith wrote: Why does SLEPc's configure.py need to know PETSC_ARCH? PETSC_ARCH is a just a string that the user made up; in the --prefix case it means nothing at all and has no information associated with it. If you are installing a SLEPC based on a --prefix install of PETSc, you can just make up any PETSC_ARCH and use it doing your ./ configure and make. If you are also doing a --prefix for SLEPC (which is likely when PETSc was done with --prefix) then once you have done make install the need for that PETSC_ARCH is gone. If you are not doing a --prefix for SLEPc then that PETSC_ARCH is what the user will need to use when they use the SLEPc. Does this not work for some reason? Barry We fixed slepc-dev so that PETSC_ARCH_NAME is not required anymore. Jose
Why did you removed PETSC_ARCH_NAME variable in makefiles?
On Thu, Nov 26, 2009 at 2:20 PM, Jose E. Roman jroman at dsic.upv.es wrote: On 25/11/2009, Barry Smith wrote: Why does SLEPc's configure.py need to know PETSC_ARCH? PETSC_ARCH is a just a string that the user made up; in the --prefix case it means nothing at all and has no information associated with it. If you are installing a SLEPC based on a --prefix install of PETSc, you can just make up any PETSC_ARCH and use it doing your ./configure and make. If you are also doing a --prefix for SLEPC (which is likely when PETSc was done with --prefix) then once you have done make install the need for that PETSC_ARCH is gone. If you are not doing a --prefix for SLEPc then that PETSC_ARCH is what the user will need to use when they use the SLEPc. Does this not work for some reason? ?Barry We fixed slepc-dev so that PETSC_ARCH_NAME is not required anymore. Jose, could you elaborate a bit what would the rules be now for SLEPc? Building SLEPc with a prefix build of PETSc will require SLEPc's configure to also pass explicitly a--prefix and do make install after the build? I still have to figure out how to make both models (I mean, prefix vs. multi-arch) builds work in the case of petsc4py/slepc4py and their dependencies on themselves and with core PETSc/SLEPc... -- 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 26/11/2009, Lisandro Dalcin wrote: On Thu, Nov 26, 2009 at 2:20 PM, Jose E. Roman jroman at dsic.upv.es wrote: We fixed slepc-dev so that PETSC_ARCH_NAME is not required anymore. Jose, could you elaborate a bit what would the rules be now for SLEPc? Building SLEPc with a prefix build of PETSc will require SLEPc's configure to also pass explicitly a--prefix and do make install after the build? I still have to figure out how to make both models (I mean, prefix vs. multi-arch) builds work in the case of petsc4py/slepc4py and their dependencies on themselves and with core PETSc/SLEPc... SLEPc can be setup with or without prefix, irrespective of whether PETSc is prefixed or not. Since we need a PETSC_ARCH, one could set an arbitrary value of PETSC_ARCH, then configure (with or without prefix)+make+(make install). If the user does not set PETSC_ARCH, then SLEPc's configure will tell the user to set PETSC_ARCH=unknown before invoking make. Jose
Why did you removed PETSC_ARCH_NAME variable in makefiles?
On Thu, Nov 26, 2009 at 3:21 PM, Jose E. Roman jroman at dsic.upv.es wrote: On 26/11/2009, Lisandro Dalcin wrote: On Thu, Nov 26, 2009 at 2:20 PM, Jose E. Roman jroman at dsic.upv.es wrote: We fixed slepc-dev so that PETSC_ARCH_NAME is not required anymore. Jose, could you elaborate a bit what would the rules be now for SLEPc? Building SLEPc with a prefix build of PETSc will require SLEPc's configure to also pass explicitly a--prefix and do make install after the build? I still have to figure out how to make both models (I mean, prefix vs. multi-arch) builds work in the case of petsc4py/slepc4py and their dependencies on themselves and with core PETSc/SLEPc... SLEPc can be setup with or without prefix, irrespective of whether PETSc is prefixed or not. Since we need a PETSC_ARCH, one could set an arbitrary value of PETSC_ARCH, then configure (with or without prefix)+make+(make install). If the user does not set PETSC_ARCH, then SLEPc's configure will tell the user to set PETSC_ARCH=unknown before invoking make. OK, now Jose just introduced another standard: an non-prefix SLEPc build with a prefix PETSc build is equivalent to a non-prefix PETSc with PETSC_ARCH=unknown, and... This is a nightmare... I'm a bit lost about what to support and what not in petsc4py/slepc4py... -- 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 Thu, 26 Nov 2009, Lisandro Dalcin wrote: On Thu, Nov 26, 2009 at 3:21 PM, Jose E. Roman jroman at dsic.upv.es wrote: On 26/11/2009, Lisandro Dalcin wrote: On Thu, Nov 26, 2009 at 2:20 PM, Jose E. Roman jroman at dsic.upv.es wrote: We fixed slepc-dev so that PETSC_ARCH_NAME is not required anymore. Jose, could you elaborate a bit what would the rules be now for SLEPc? Building SLEPc with a prefix build of PETSc will require SLEPc's configure to also pass explicitly a--prefix and do make install after the build? I still have to figure out how to make both models (I mean, prefix vs. multi-arch) builds work in the case of petsc4py/slepc4py and their dependencies on themselves and with core PETSc/SLEPc... SLEPc can be setup with or without prefix, irrespective of whether PETSc is prefixed or not. Since we need a PETSC_ARCH, one could set an arbitrary value of PETSC_ARCH, then configure (with or without prefix)+make+(make install). If the user does not set PETSC_ARCH, then SLEPc's configure will tell the user to set PETSC_ARCH=unknown before invoking make. OK, now Jose just introduced another standard: an non-prefix SLEPc build with a prefix PETSc build is equivalent to a non-prefix PETSc with PETSC_ARCH=unknown, and... This is a nightmare... I'm a bit lost about what to support and what not in petsc4py/slepc4py... 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. 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. Satish
Why did you removed PETSC_ARCH_NAME variable in makefiles?
Lisandro,
That change will certainly NOT be reverted. PETSC_ARCH_NAME!
what the heck kind of variable name is that?
I need to understand the reason for PETSC_ARCH_NAME, then we can
come up with some solution. What is the difference between
PETSC_ARCH_NAME and PETSC_ARCH? Is it only needed when --prefix is
used (so PETSC_ARCH does not exist), if so, exactly why is it needed,
the whole idea behind --prefix is to eliminate PETSC_ARCH, so why is
it needed? How is PETSC_ARCH_NAME used?
Barry
On Nov 25, 2009, at 10:14 AM, Lisandro Dalcin wrote:
Barry, an outcome of the two changesets below:
changeset: 14451:b289577caf8f
user:barrysmith at bsmith-laptop.mcs.anl.gov
date:Mon Oct 19 16:31:16 2009 -0500
summary: update to install.py to ONLY use RDict.db (and not
command line)
changeset: 14383:447d34bd2d4b
user:barrysmith at bsmith-laptop.mcs.anl.gov
date:Thu Oct 08 16:33:59 2009 -0500
summary: finished cleaning up makefiles, moved charactoristic.h to
include location standard place where it is easy to use
was that these two lines in config/PETSc/utilities/arch.py were
removed:
# SLEPc configure need this info
self.addMakeMacro('PETSC_ARCH_NAME',self.arch)
SLEPc and petsc4py/slepc4py/tao4py relies on this variable being
defined in makefiles. There is now a new way to get the original name
of the build-time $PETSC_ARCH? If not, any chance this change could be
reverted?
--
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?
Barry,
I think the use of PETSC_ARCH_NAME is motivated by a request I sent in
December last year, see
http://lists.mcs.anl.gov/pipermail/petsc-dev/2008-December/001120.html
We use it when configuring SLEPc with a prefix-based PETSc. If you
remove this variable, we will have to think about an alternative way
of supporting that case.
Jose
On 25/11/2009, Barry Smith wrote:
Lisandro,
That change will certainly NOT be reverted. PETSC_ARCH_NAME!
what the heck kind of variable name is that?
I need to understand the reason for PETSC_ARCH_NAME, then we can
come up with some solution. What is the difference between
PETSC_ARCH_NAME and PETSC_ARCH? Is it only needed when --prefix is
used (so PETSC_ARCH does not exist), if so, exactly why is it
needed, the whole idea behind --prefix is to eliminate PETSC_ARCH,
so why is it needed? How is PETSC_ARCH_NAME used?
Barry
On Nov 25, 2009, at 10:14 AM, Lisandro Dalcin wrote:
Barry, an outcome of the two changesets below:
changeset: 14451:b289577caf8f
user:barrysmith at bsmith-laptop.mcs.anl.gov
date:Mon Oct 19 16:31:16 2009 -0500
summary: update to install.py to ONLY use RDict.db (and not
command line)
changeset: 14383:447d34bd2d4b
user:barrysmith at bsmith-laptop.mcs.anl.gov
date:Thu Oct 08 16:33:59 2009 -0500
summary: finished cleaning up makefiles, moved charactoristic.h
to
include location standard place where it is easy to use
was that these two lines in config/PETSc/utilities/arch.py were
removed:
# SLEPc configure need this info
self.addMakeMacro('PETSC_ARCH_NAME',self.arch)
SLEPc and petsc4py/slepc4py/tao4py relies on this variable being
defined in makefiles. There is now a new way to get the original name
of the build-time $PETSC_ARCH? If not, any chance this change could
be
reverted?
--
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 Wed, Nov 25, 2009 at 3:19 PM, Barry Smith bsmith at mcs.anl.gov wrote: ?Lisandro, ? ? That change will certainly NOT be reverted. PETSC_ARCH_NAME! what the heck kind of variable name is that? I agree the name could be messy or misleading. But so is PETSC_ARCH, which should actually be something like PETSC_CONF, right? ? ? I need to understand the reason for PETSC_ARCH_NAME, then we can come up with some solution. OK. Let see. What is the difference between PETSC_ARCH_NAME and PETSC_ARCH? None Is it only needed when --prefix is used (so PETSC_ARCH does not exist), Yes. if so, exactly why is it needed, the whole idea behind --prefix is to eliminate PETSC_ARCH, In the particular case of petsc4py, the Python extension module get's installed as lib/$PETSC_ARCH/PETSc.so. Then, for --prefix installs of PETSc, I use the PETSC_ARCH_NAME (obtained from parsing makefiles, as for many other configuration stuff). so why is it needed? How is PETSC_ARCH_NAME used? I can certainly change my way of doing things in petsc4py. Perhaps I should install as lib/PETSc.so for --prefix PETSc builds? I said this before, but let's go one more time: I find --prefix installs of PETSc a bit useless for general-purpose installations. Supose as sysadmin make install PETSc in a cluster. She likely built using a C as language, double precision real scalars, 32bit integers, (dbg/opt?). Such configuration does not fit all applications. Some users may require C++, other may want complex, others may want to run her own codes with a debug version. Then I see VERY little point on --prefix builds of PETSc. Moreover, in our machines at CIMEC I maintain central installations of PETSc at /usr/local/petsc/3.0.0. This is not done at all with --prefix and make install, instead, /usr/local/petsc/3.0.0 is a HG clone of release-3.0.0. For all these reasons, petsc4py stills support clearly separated lib/$PETSC_ARCH/PETSc.so ext modules. For example, switching from debug to optimized is just a matter of export PETSC_ARCH=opt-arch-name and python script.py. Perhaps now it is the time to change a bit this, but I certainly need some advice/discussion/comments from your side. -- 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 25, 2009, at 12:39 PM, Jose E. Roman wrote:
Barry,
I think the use of PETSC_ARCH_NAME is motivated by a request I sent
in December last year, see
http://lists.mcs.anl.gov/pipermail/petsc-dev/2008-December/001120.html
Ok, here is the message: SLEPc's configure.py uses the value of
$PETSC_ARCH in order to setup everything for installation. We never
had a $SLEPC_ARCH variable because our configure.py does not add
platform-dependent functionality. Now the problem comes when PETSc has
been configured with --prefix and installed with make install. In that
case, $PETSC_ARCH is no longer available and SLEPc's configure.py is
in trouble. A simple workaround would be that PETSc's configure (or
make install) would add a variable (e.g. PETSC_ARCH_NAME) in file
petscvariables. We parse this file so the arch name would be readily
available even if $PETSC_ARCH is undefined. Can someone do this? Other
solutions are welcome.
Why does SLEPc's configure.py need to know PETSC_ARCH? PETSC_ARCH is a
just a string that the user made up; in the --prefix case it means
nothing at all and has no information associated with it.
If you are installing a SLEPC based on a --prefix install of PETSc,
you can just make up any PETSC_ARCH and use it doing your ./configure
and make. If you are also doing a --prefix for SLEPC (which is likely
when PETSc was done with --prefix) then once you have done make
install the need for that PETSC_ARCH is gone. If you are not doing a --
prefix for SLEPc then that PETSC_ARCH is what the user will need to
use when they use the SLEPc. Does this not work for some reason?
Barry
We use it when configuring SLEPc with a prefix-based PETSc. If you
remove this variable, we will have to think about an alternative way
of supporting that case.
Jose
On 25/11/2009, Barry Smith wrote:
Lisandro,
That change will certainly NOT be reverted. PETSC_ARCH_NAME!
what the heck kind of variable name is that?
I need to understand the reason for PETSC_ARCH_NAME, then we can
come up with some solution. What is the difference between
PETSC_ARCH_NAME and PETSC_ARCH? Is it only needed when --prefix is
used (so PETSC_ARCH does not exist), if so, exactly why is it
needed, the whole idea behind --prefix is to eliminate PETSC_ARCH,
so why is it needed? How is PETSC_ARCH_NAME used?
Barry
On Nov 25, 2009, at 10:14 AM, Lisandro Dalcin wrote:
Barry, an outcome of the two changesets below:
changeset: 14451:b289577caf8f
user:barrysmith at bsmith-laptop.mcs.anl.gov
date:Mon Oct 19 16:31:16 2009 -0500
summary: update to install.py to ONLY use RDict.db (and not
command line)
changeset: 14383:447d34bd2d4b
user:barrysmith at bsmith-laptop.mcs.anl.gov
date:Thu Oct 08 16:33:59 2009 -0500
summary: finished cleaning up makefiles, moved
charactoristic.h to
include location standard place where it is easy to use
was that these two lines in config/PETSc/utilities/arch.py were
removed:
# SLEPc configure need this info
self.addMakeMacro('PETSC_ARCH_NAME',self.arch)
SLEPc and petsc4py/slepc4py/tao4py relies on this variable being
defined in makefiles. There is now a new way to get the original
name
of the build-time $PETSC_ARCH? If not, any chance this change
could be
reverted?
--
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 25, 2009, at 1:03 PM, Lisandro Dalcin wrote: On Wed, Nov 25, 2009 at 3:19 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro, That change will certainly NOT be reverted. PETSC_ARCH_NAME! what the heck kind of variable name is that? I agree the name could be messy or misleading. It is confusing because then PETSc has a PETSC_ARCH and a PETSC_ARCH_NAME variable and having two very similar names with related or identical functionality adds unneeded complexity. The whole point of --prefix is to eliminate the need for and concept of PETSC_ARCH, so to have it still be there (in that you need PETSC_ARCH_NAME) is bizarre and confusing. But so is PETSC_ARCH, which should actually be something like PETSC_CONF, right? I need to understand the reason for PETSC_ARCH_NAME, then we can come up with some solution. OK. Let see. What is the difference between PETSC_ARCH_NAME and PETSC_ARCH? None Is it only needed when --prefix is used (so PETSC_ARCH does not exist), Yes. if so, exactly why is it needed, the whole idea behind --prefix is to eliminate PETSC_ARCH, In the particular case of petsc4py, the Python extension module get's installed as lib/$PETSC_ARCH/PETSc.so. Then, for --prefix installs of PETSc, I use the PETSC_ARCH_NAME (obtained from parsing makefiles, as for many other configuration stuff). so why is it needed? How is PETSC_ARCH_NAME used? I can certainly change my way of doing things in petsc4py. Perhaps I should install as lib/PETSc.so for --prefix PETSc builds? Absolutely, the PETSC_ARCH should NOT be in the path there. By keeping the $PETSC_ARCH around when using the --prefix you are totally abusing the whole concept of --prefix and have some weird half-assed creature that is not really traditional PETSc or --prefix style. You are doing the --prefix stuff wrong (see my note below). I said this before, but let's go one more time: I find --prefix installs of PETSc a bit useless for general-purpose installations. Supose as sysadmin make install PETSc in a cluster. She likely built using a C as language, double precision real scalars, 32bit integers, (dbg/opt?). Such configuration does not fit all applications. Some users may require C++, other may want complex, others may want to run her own codes with a debug version. Then I see VERY little point on --prefix builds of PETSc. Moreover, in our machines at CIMEC I maintain central installations of PETSc at /usr/local/petsc/3.0.0. This is not done at all with --prefix and make install, instead, /usr/local/petsc/3.0.0 is a HG clone of release-3.0.0. For all these reasons, petsc4py stills support clearly separated lib/$PETSC_ARCH/PETSc.so ext modules. For example, switching from debug to optimized is just a matter of export PETSC_ARCH=opt-arch-name and python script.py. Perhaps now it is the time to change a bit this, but I certainly need some advice/discussion/comments from your side. I do agree with your about --prefix. It is pandering to the crowd of how gnu does things is the best and only way things should ever be done and if you don't do it that way then you are a complete idiot school. But the reason we support it is that its is very commonly asked for and EXPECTED by many, many people. It is a hopeless cause to convince these people that our model is better. I ignored this crowd for many, many years but finally broke down and figured out a fairly reasonable (though perhaps not perfect) way of doing it the gnu way also so the many people who live and die with the ./configure -- prefix; make ; make install are happy and can just do their approach (even though it is a silly and bad model). So basically I am asking you and Jose to support the traditional PETSc approach and the pure --prefix approach and not have some intermediate thing that does not fully follow the GNU --prefix model. 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
Why did you removed PETSC_ARCH_NAME variable in makefiles?
On Wed, 25 Nov 2009, Lisandro Dalcin wrote: I said this before, but let's go one more time: I find --prefix installs of PETSc a bit useless for general-purpose installations. Supose as sysadmin make install PETSc in a cluster. She likely built using a C as language, double precision real scalars, 32bit integers, (dbg/opt?). Such configuration does not fit all applications. Some users may require C++, other may want complex, others may want to run her own codes with a debug version. Then I see VERY little point on --prefix builds of PETSc. Moreover, in our machines at CIMEC I maintain central installations of PETSc at /usr/local/petsc/3.0.0. This is not done at all with --prefix and make install, instead, /usr/local/petsc/3.0.0 is a HG clone of release-3.0.0. The idea with prefix PETSc is - one does not use the same prefix for all installs. Here PETSC_DIR+PETSC_ARCH is the unique key from the usage side. no prefix mode: [only PETSC_ARCH changes] PETSC_ARCH=build1 PETSC_ARCH=build2 prefix mode: [only PETSC_DIR - which is the prefix value, is changed] prefix=/path1 prefix=/path2 Note: [using a different prefix path for different installs] is a common thing to do with autoconf packages as well. The difference with PETSc is - for the rest of the world [of packages] - a single install usually suffices. But for PETSc - we need multiple installs. I still stick with the default model when installing petsc on clusters. as switching 'only PETSC_ARCH' is more userfriendly. [and its easier for me to install in this mode] Satish
