November 2009 - petsc-dev - mailman3.cels.anl.gov

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Satish Balay 27 Nov '09

27 Nov '09

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

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Barry Smith 27 Nov '09

27 Nov '09

On Nov 27, 2009, at 1:24 PM, Lisandro Dalcin wrote: > On Fri, Nov 27, 2009 at 2:21 AM, Satish Balay <balay(a)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. 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). Barry > > 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

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Matthew Knepley 27 Nov '09

27 Nov '09

On Fri, Nov 27, 2009 at 1:45 PM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > On Fri, Nov 27, 2009 at 4:33 PM, Matthew Knepley <knepley(a)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(a)gmail.com> > wrote: > >> > >> On Fri, Nov 27, 2009 at 2:21 AM, Satish Balay <balay(a)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

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Lisandro Dalcin 27 Nov '09

27 Nov '09

On Fri, Nov 27, 2009 at 4:33 PM, Matthew Knepley <knepley(a)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(a)gmail.com> wrote: >> >> On Fri, Nov 27, 2009 at 2:21 AM, Satish Balay <balay(a)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

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Matthew Knepley 27 Nov '09

27 Nov '09

Why not just hash the RDict.db? Matt On Fri, Nov 27, 2009 at 1:24 PM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > On Fri, Nov 27, 2009 at 2:21 AM, Satish Balay <balay(a)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

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Lisandro Dalcin 27 Nov '09

27 Nov '09

On Fri, Nov 27, 2009 at 2:21 AM, Satish Balay <balay(a)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

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Satish Balay 26 Nov '09

26 Nov '09

On Thu, 26 Nov 2009, Lisandro Dalcin wrote: > On Thu, Nov 26, 2009 at 3:21 PM, Jose E. Roman <jroman(a)dsic.upv.es> wrote: > > > > On 26/11/2009, Lisandro Dalcin wrote: > > > >> On Thu, Nov 26, 2009 at 2:20 PM, Jose E. Roman <jroman(a)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

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Lisandro Dalcin 26 Nov '09

26 Nov '09

On Thu, Nov 26, 2009 at 3:21 PM, Jose E. Roman <jroman(a)dsic.upv.es> wrote: > > On 26/11/2009, Lisandro Dalcin wrote: > >> On Thu, Nov 26, 2009 at 2:20 PM, Jose E. Roman <jroman(a)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

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Jose E. Roman 26 Nov '09

26 Nov '09

On 26/11/2009, Lisandro Dalcin wrote: > On Thu, Nov 26, 2009 at 2:20 PM, Jose E. Roman <jroman(a)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

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Lisandro Dalcin 26 Nov '09

26 Nov '09

On Thu, Nov 26, 2009 at 2:20 PM, Jose E. Roman <jroman(a)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

1 0