changes to PETSc-dev bmake system and library locations
I just downloaded the new updates and tried configuring the development
version and get the following python errors...It may be a problem on my
side. I'll try with a new clone of the repository...
akita % ./config/configure.py --with-c++
=
Configuring PETSc to compile on your system
=*
UNABLE to FIND MODULE for config/configure.py
---
No module named Fiat
*
File "./config/configure.py", line 175, in petsc_configure
framework =
config.framework.Framework(sys.argv[1:]+['--configModules=PETSc.Configure','--optionsModule=PETSc.compilerOptions'],
loadArgDB = 0)
File
"/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
line 91, in __init__
self.createChildren()
File
"/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
line 317, in createChildren
self.getChild(moduleName)
File
"/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
line 302, in getChild
config.setupDependencies(self)
File "/sandbox/tmunson/projects/petsc-dev/python/PETSc/Configure.py",
line 44, in setupDependencies
utilityObj =
self.framework.require('PETSc.'+d+'.'+utilityName, self)
File
"/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
line 322, in require
config = self.getChild(moduleName, keywordArgs)
File
"/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
line 302, in getChild
config.setupDependencies(self)
File "/sandbox/tmunson/projects/petsc-dev/python/PETSc/packages/FFC.py",
line 11, in setupDependencies
self.fiat = self.framework.require('config.packages.Fiat', self)
File
"/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
line 322, in require
config = self.getChild(moduleName, keywordArgs)
File
"/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
line 275, in getChild
type = __import__(moduleName, globals(), locals(),
['Configure']).Configureakita %
!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!
Todd Munson (630) 252-4279 office
Argonne National Laboratory (630) 252-5986 fax
9700 S. Cass Ave.tmunson at mcs.anl.gov
Argonne, IL 60439http://www.mcs.anl.gov/~tmunson
On Sun, 10 Jun 2007, Barry Smith wrote:
>
>
> On Sun, 10 Jun 2007, Matthew Knepley wrote:
>
> > This is very vague concerning the structure of exernalpackages. I cannot
> > tell
> > where libraries are supposed to end up, and how/when/why they might be
> > moved.
>
> They end up in
>
>$PETSC_ARCH/lib (same place as PETSc libraries, without a make install) and
>prefix/lib (with a make install)
>
> > It seems that the directory information coming from PETSc/package.py
> > has also changed.
>
>Yes. package.py had a /lib hardwired to the end of the install directory
> returned by the particular package. Now the particular packages set the
> entire path where the library goes (that is a /lib is not automatically
> appended).
>
>Barry
>
> >
> > Matt
> >
> > On 6/8/07, Barry Smith wrote:
> > >
> > > PETSc-dev users,
> > >
> > > After picking Satish's brain, I have made a set of changes to
> > > petsc-dev related to compiling and linking programs.
> > >
> > >Goal: Support the GNU; config/configure.py; make; make install model
> > > including all external packages PETSc builds for you. After "make install"
> > > PETSC_ARCH should not be needed.
> > >
> > >Constraints:
> > > * Allow skipping the "make install" step and yet having everything
> > > fully functional even with shared and dynamic libraries
> > > * Allow multiple builds in the non-"make install" approach which you can
> > > switch between by changing PETSC_ARCH
> > > * Not require any file links
> > > * A system that does not mix generated files and non-generated in the same
> > > directory in $PETSC_DIR
> > > * A system no more complicated then the previous version.
> > >
> > > Solution:
> > >
> > > In place, before "make install"
> > >
> > > petsc-dev/include same as now
> > > /bin same as now
> > > /conf basically the same as bmake/common was
> > > $PETSC_ARCH/include generated includes: petscconf.h
> > > petscfix.h ..
> > > lib generated libraries
> > > bin generated programs
> > > conf basically the same as
> > > bmake/$PETSC_ARCH/
> > >
changes to PETSc-dev bmake system and library locations
Maybe you have an old BuildSystem?
Matt
On 6/11/07, Todd Munson wrote:
>
> I just downloaded the new updates and tried configuring the development
> version and get the following python errors...It may be a problem on my
> side. I'll try with a new clone of the repository...
>
> akita % ./config/configure.py --with-c++
> =
> Configuring PETSc to compile on your system
> =*
> UNABLE to FIND MODULE for config/configure.py
> ---
> No module named Fiat
> *
>
> File "./config/configure.py", line 175, in petsc_configure
> framework =
> config.framework.Framework(sys.argv[1:]+['--configModules=PETSc.Configure','--optionsModule=PETSc.compilerOptions'],
> loadArgDB = 0)
> File
> "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> line 91, in __init__
> self.createChildren()
> File
> "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> line 317, in createChildren
> self.getChild(moduleName)
> File
> "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> line 302, in getChild
> config.setupDependencies(self)
> File "/sandbox/tmunson/projects/petsc-dev/python/PETSc/Configure.py",
> line 44, in setupDependencies
> utilityObj =
> self.framework.require('PETSc.'+d+'.'+utilityName, self)
> File
> "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> line 322, in require
> config = self.getChild(moduleName, keywordArgs)
> File
> "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> line 302, in getChild
> config.setupDependencies(self)
> File "/sandbox/tmunson/projects/petsc-dev/python/PETSc/packages/FFC.py",
> line 11, in setupDependencies
> self.fiat = self.framework.require('config.packages.Fiat', self)
> File
> "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> line 322, in require
> config = self.getChild(moduleName, keywordArgs)
> File
> "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> line 275, in getChild
> type = __import__(moduleName, globals(), locals(),
> ['Configure']).Configureakita %
>
>
>
> !+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!
> Todd Munson (630) 252-4279 office
> Argonne National Laboratory (630) 252-5986 fax
> 9700 S. Cass Ave.tmunson at mcs.anl.gov
> Argonne, IL 60439http://www.mcs.anl.gov/~tmunson
>
>
> On Sun, 10 Jun 2007, Barry Smith wrote:
>
> >
> >
> > On Sun, 10 Jun 2007, Matthew Knepley wrote:
> >
> > > This is very vague concerning the structure of exernalpackages. I cannot
> > > tell
> > > where libraries are supposed to end up, and how/when/why they might be
> > > moved.
> >
> > They end up in
> >
> >$PETSC_ARCH/lib (same place as PETSc libraries, without a make install)
> > and
> >prefix/lib (with a make install)
> >
> > > It seems that the directory information coming from PETSc/package.py
> > > has also changed.
> >
> >Yes. package.py had a /lib hardwired to the end of the install directory
> > returned by the particular package. Now the particular packages set the
> > entire path where the library goes (that is a /lib is not automatically
> > appended).
> >
> >Barry
> >
> > >
> > > Matt
> > >
> > > On 6/8/07, Barry Smith wrote:
> > > >
> > > > PETSc-dev users,
> > > >
> > > > After picking Satish's brain, I have made a set of changes to
> > > > petsc-dev related to compiling and linking programs.
> > > >
> > > >Goal: Support the GNU; config/configure.py; make; make install model
> > > > including all external packages PETSc builds for you. After "make
> > > > install"
> > > > PETSC_ARCH should not be needed.
> > > >
> > > >Constraints:
> > > > * Allow skipping the "make install" step and yet having everything
> > > > fully functional even with shared and dynamic libraries
> > > > * Allow multiple builds in the non-"make install" approach which you can
> > > > switch between by changing PETSC_ARCH
> > > > * Not require any file links
> > > > * A system that does not mix generated files and non-generated in the
> > > > same
> > > > directory in $PETSC_DIR
> > > > * A system no more complicated then the previous version.
> > > >
> > > > Solution:
> > > >
> > > > In place, before "make install"
> > > >
> > > > petsc-dev/include same as now
> > > > /bin same as now
> > > > /conf basically the same as bmake/common
> > > > was
changes to PETSc-dev bmake system and library locations
I had configured and built petsc-dev prior to updating to the new
configuration system. That did not work...once the update happens
things get screwed up and nothing in the build system works. Maybe the
BuildSystem module was old, but I would figure that it should get updated
when you check for its existence...
Anyway, I cloned a new copy of petsc-dev and everything now builds...
Cheers, Todd.
On Mon, 11 Jun 2007, Matthew Knepley wrote:
> Maybe you have an old BuildSystem?
>
> Matt
>
> On 6/11/07, Todd Munson wrote:
> >
> > I just downloaded the new updates and tried configuring the development
> > version and get the following python errors...It may be a problem on my
> > side. I'll try with a new clone of the repository...
> >
> > akita % ./config/configure.py --with-c++
> > =
> > Configuring PETSc to compile on your system
> > =*
> > UNABLE to FIND MODULE for config/configure.py
> > ---
> > No module named Fiat
> > *
> >
> > File "./config/configure.py", line 175, in petsc_configure
> > framework =
> > config.framework.Framework(sys.argv[1:]+['--configModules=PETSc.Configure','--optionsModule=PETSc.compilerOptions'],
> > loadArgDB = 0)
> > File
> > "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> > line 91, in __init__
> > self.createChildren()
> > File
> > "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> > line 317, in createChildren
> > self.getChild(moduleName)
> > File
> > "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> > line 302, in getChild
> > config.setupDependencies(self)
> > File "/sandbox/tmunson/projects/petsc-dev/python/PETSc/Configure.py",
> > line 44, in setupDependencies
> > utilityObj =
> > self.framework.require('PETSc.'+d+'.'+utilityName, self)
> > File
> > "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> > line 322, in require
> > config = self.getChild(moduleName, keywordArgs)
> > File
> > "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> > line 302, in getChild
> > config.setupDependencies(self)
> > File "/sandbox/tmunson/projects/petsc-dev/python/PETSc/packages/FFC.py",
> > line 11, in setupDependencies
> > self.fiat = self.framework.require('config.packages.Fiat', self)
> > File
> > "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> > line 322, in require
> > config = self.getChild(moduleName, keywordArgs)
> > File
> > "/sandbox/tmunson/projects/petsc-dev/python/BuildSystem/config/framework.py",
> > line 275, in getChild
> > type = __import__(moduleName, globals(), locals(),
> > ['Configure']).Configureakita %
> >
> >
> >
> > !+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!+-+!
> > Todd Munson (630) 252-4279 office
> > Argonne National Laboratory (630) 252-5986 fax
> > 9700 S. Cass Ave.tmunson at mcs.anl.gov
> > Argonne, IL 60439http://www.mcs.anl.gov/~tmunson
> >
> >
> > On Sun, 10 Jun 2007, Barry Smith wrote:
> >
> > >
> > >
> > > On Sun, 10 Jun 2007, Matthew Knepley wrote:
> > >
> > > > This is very vague concerning the structure of exernalpackages. I
> > > > cannot tell
> > > > where libraries are supposed to end up, and how/when/why they might be
> > > > moved.
> > >
> > > They end up in
> > >
> > >$PETSC_ARCH/lib (same place as PETSc libraries, without a make
> > > install) and
> > >prefix/lib (with a make install)
> > >
> > > > It seems that the directory information coming from PETSc/package.py
> > > > has also changed.
> > >
> > >Yes. package.py had a /lib hardwired to the end of the install
> > > directory
> > > returned by the particular package. Now the particular packages set the
> > > entire path where the library goes (that is a /lib is not automatically
> > > appended).
> > >
> > >Barry
> > >
> > > >
> > > > Matt
> > > >
> > > > On 6/8/07, Barry Smith wrote:
> > > > >
> > > > > PETSc-dev users,
> > > > >
> > > > > After picking Satish's brain, I have made a set of changes to
> > > > > petsc-dev related to compiling and linking programs.
> > > > >
> > > > >Goal: Support the GNU; config/configure.py; make; make install
> > > > > model
> > > > > including all external packages PETSc builds for you. After "make
> > > > > install"
> > > > > PETSC_ARCH should not be needed.
> > > > >
> > > > >Constraints:
> > > > > * Allow skipping the "make install" step and yet having everything
> > > > > ful
changes to PETSc-dev bmake system and library locations
On 6/8/07, Barry Smith wrote:
>Goal: Support the GNU; config/configure.py; make; make install model
> including all external packages PETSc builds for you. After "make install"
> PETSC_ARCH should not be needed.
Barry, I really do not like this... this approach does not permit to
have many configurations installed under a common $PERSC_DIR.
Futhermore, the 'build' directory does not have de same structure as
the 'install' directory.
I have to strongly ask you for revert this and review the patch I
sended to petsc-maint. The 'bmake' plus 'lib/$PETSC_ARCH' approach was
really good for me. I know, following the GNU model is interesting and
compatible with normal practice... but I am definitely not sure if it
is the right way for a complex package like PETSc, were you can
compile it with many config options and many optional packages, and
have all this variantas fully functionaly available in a central
location...
>Constraints:
> * Allow skipping the "make install" step and yet having everything
> fully functional even with shared and dynamic libraries
> * Allow multiple builds in the non-"make install" approach which you can
> switch between by changing PETSC_ARCH
> * Not require any file links
> * A system that does not mix generated files and non-generated in the same
> directory in $PETSC_DIR
> * A system no more complicated then the previous version.
>
> Solution:
>
> In place, before "make install"
>
> petsc-dev/include same as now
> /bin same as now
> /conf basically the same as bmake/common was
> $PETSC_ARCH/include generated includes: petscconf.h petscfix.h
> ..
> lib generated libraries
> bin generated programs
> conf basically the same as bmake/$PETSC_ARCH/
> except not the include files
>
> After "make install"
>
> prefix/include all includes
> /bin all programs, including mpiexec, mpicc if
> generated
> /conf the stuff previous in bmake/common and
> bmake/$PETSC_ARCH
> /lib the libraries, including from external
> packages
>
> The whole trick is that in the PETSc bmake files (now conf files :-)) the
> $PETSC_ARCH/
> disappears in the "make install" version.
>
> I have fixed the external packages MPI.py, BlasLapack.py and Chaco.py but the
> others
> need to be modified to stick their libraries and includes in the new correct
> place.
>
> The only change you should need to your makefiles is to replace
> include ${PETSC_DIR}/bmake/common/base with
> include ${PETSC_DIR}/conf/base
> Bug reports to petsc-maint at mcs.anl.gov questions to petsc-dev at
> mcs.anl.gov
>
>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
changes to PETSc-dev bmake system and library locations
On Mon, 11 Jun 2007, Todd Munson wrote: > > I had configured and built petsc-dev prior to updating to the new > configuration system. That did not work...once the update happens > things get screwed up and nothing in the build system works. Maybe the > BuildSystem module was old, but I would figure that it should get updated > when you check for its existence... http://www-unix.mcs.anl.gov/petsc/petsc-as/developers/index.html you are supporsed to do make pull or pull each repo individually cd petsc-dev hg pull -u cd python/BuildSystem hg pull -u Satish
changes to PETSc-dev bmake system and library locations
On Mon, 11 Jun 2007, Lisandro Dalcin wrote: > On 6/8/07, Barry Smith wrote: > >Goal: Support the GNU; config/configure.py; make; make install model > > including all external packages PETSc builds for you. After "make install" > > PETSC_ARCH should not be needed. > > Barry, I really do not like this... this approach does not permit to > have many configurations installed under a common $PERSC_DIR. > Futhermore, the 'build' directory does not have de same structure as > the 'install' directory. > > I have to strongly ask you for revert this and review the patch I > sended to petsc-maint. The 'bmake' plus 'lib/$PETSC_ARCH' approach was > really good for me. I know, following the GNU model is interesting and > compatible with normal practice... but I am definitely not sure if it > is the right way for a complex package like PETSc, were you can > compile it with many config options and many optional packages, and > have all this variantas fully functionaly available in a central > location... Lisandro, There is nothing sepcial about having all installs inside a single PETSC_DIR. However you can still have multiple configure installs by specifying different 'prefix' for each configure. I believe this is how autoconf/gnu install model is supporsed to work. The way the 2 models [install and non-install] are equivalent is: in the prefix model - the user specifies prefix just like any other package. For eg: --prefix=/usr/local --download-mpich This should install both the packages [PETSc & MPI] in /usr/local/[bin,include,lib] In the non-prefix mode, this 'prefix' path '/usr/local/ is eqivalent to $PETSC_DIR/$PETSC_ARCH. i.e all packages [PETSc & MPI] should be installed inside: $PETSC_DIR/$PETSC_ARCH/[bin,include,lib] etc.. I agree that there is a now a difference in usage in the install mode. The user could switch between different configured builds by changing PETSC_ARCH in the non-prefix model. In the install model, now the user has to change PETSC_DIR to acomplish the same. If you wish to have all all the libs inside a single PETSC_DIR, then there is no reason to use 'install' model. [i.e you can install PETSc in /usr/local/petsc using the non-install model. The sources take extra speace. But at the same time, you benefit from them being available during debugging] Satish
changes to PETSc-dev bmake system and library locations
On 6/11/07, Satish Balay wrote: > On Mon, 11 Jun 2007, Lisandro Dalcin wrote: > > > There is nothing sepcial about having all installs inside a single > PETSC_DIR. > in the prefix model - the user specifies prefix just like any other > package. For eg: > > --prefix=/usr/local --download-mpich > > This should install both the packages [PETSc & MPI] in > /usr/local/[bin,include,lib] > I see the benefits now, I will try to update my build system for petsc4py and see what happens... Can you please tell me what would be now the correct way to differentiate a 'build' mode and an 'install' mode? Just using directory structure? -- 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
changes to PETSc-dev bmake system and library locations
On Mon, 11 Jun 2007, Satish Balay wrote: > However you can still have multiple configure installs by > specifying different 'prefix' for each configure. I believe this is > how autoconf/gnu install model is supporsed to work. I should add that one motivation to support gnu/autoconf? 'make insall' model as closly as possible - is to make it easy for 'packagers' [deb,rpm etc..] to package PETSc [atleast the default config - whatever that means] and make it available for their respective distributions. Currently we only have only debian/freebsd packages - and nothing more. And I'm hoping that these packagers have their own models for installing multiple configs [via different prefix], so potentially multiple variants of PETSc config can be packaged [if they chose to do it]. However I think the requirement of 'PETSC_DIR' might still be a minor hurdle for this mode. [the alternative would be providing compiler wrappers but thats a different discussion] Satish
changes to PETSc-dev bmake system and library locations
On Mon, 11 Jun 2007, Lisandro Dalcin wrote: > On 6/11/07, Satish Balay wrote: > > There is nothing sepcial about having all installs inside a single > > PETSC_DIR. in the prefix model - the user specifies prefix just > > like any other package. For eg: > > > > --prefix=/usr/local --download-mpich > > > > This should install both the packages [PETSc & MPI] in > > /usr/local/[bin,include,lib] > > > > I see the benefits now, I will try to update my build system for > petsc4py and see what happens... > > Can you please tell me what would be now the correct way to > differentiate a 'build' mode and an 'install' mode? Just using > directory structure? If its based on PETSC_ARCH/PETSC_DIR from makefiles, things should still work - [as PETSC_ARCH will be ignored by makefiles in the prefix-install version] Not sure what can be done or other 'automatic' detection systems. Perhaps Barry has ideas on this. Satish
changes to PETSc-dev bmake system and library locations
On 6/11/07, Satish Balay wrote: > I should add that one motivation to support gnu/autoconf? 'make > insall' model as closly as possible - is to make it easy for > 'packagers' [deb,rpm etc..] to package PETSc OK, this make sense... I'll try this when I have some free time, I've been playing a bit generating rpm's for Fedora. [atleast the default > config - whatever that means] and make it available for their > respective distributions. Currently we only have only debian/freebsd > packages - and nothing more. > > And I'm hoping that these packagers have their own models for > installing multiple configs [via different prefix], so potentially > multiple variants of PETSc config can be packaged [if they chose to do > it]. > > However I think the requirement of 'PETSC_DIR' might still be a minor > hurdle for this mode. [the alternative would be providing compiler > wrappers but thats a different discussion] > > Satish > > -- 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
changes to PETSc-dev bmake system and library locations
I think 'conf/variables' needs a bit more of work. I am not sure about
what to do, the problem is here:
PETSC_LIB_DIR = ${PETSC_DIR}/${PETSC_ARCH}/lib
PETSC_INCLUDE = -I${PETSC_DIR}
-I${PETSC_DIR}/${PETSC_ARCH}/include -I${PETSC_DIR}/include \
${PACKAGES_INCLUDES} ${TAU_DEFS}
${TAU_INCLUDE} ${PETSC_BLASLAPACK_FLAGS}
As you can see, there are references to $PESC_ARCH. So there are two
potential problems using a 'install' version:
1.- If $PETSC_ARCH is not defined, some paths are of the form
'/usr/local/petsc//lib'. Not sure is the double '//' could be
problematic.
2.- If $PETSC_ARCH is defined somewhere (user makefiles or even
environment), bad paths will be generated, and ${PETSC_LIB_DIR} is
definitely broken.
Is all this OK? Or my hg pull + hg update failed?
On 6/11/07, Lisandro Dalcin wrote:
> On 6/11/07, Satish Balay wrote:
> > I should add that one motivation to support gnu/autoconf? 'make
> > insall' model as closly as possible - is to make it easy for
> > 'packagers' [deb,rpm etc..] to package PETSc
>
> OK, this make sense... I'll try this when I have some free time, I've
> been playing a bit generating rpm's for Fedora.
>
>
> [atleast the default
> > config - whatever that means] and make it available for their
> > respective distributions. Currently we only have only debian/freebsd
> > packages - and nothing more.
> >
> > And I'm hoping that these packagers have their own models for
> > installing multiple configs [via different prefix], so potentially
> > multiple variants of PETSc config can be packaged [if they chose to do
> > it].
> >
> > However I think the requirement of 'PETSC_DIR' might still be a minor
> > hurdle for this mode. [the alternative would be providing compiler
> > wrappers but thats a different discussion]
> >
> > Satish
> >
> >
>
>
> --
> 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
>
--
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
more comments about new build system
If one of the goals of the new build system is to be more symmetric with the GNU model, in order to make life easier for packagers, so I think the '$PETSC_PREFIX/conf' location should be renamed, perhaps to '$PETSC_PREFIX/share/petsc'. I believe 'conf' is not a 'standard' location. -- 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
more comments about new build system
Lisandro, Good point. etc was also suggested. Adding the petsc is kind of ugly with the non-installed version, for example petsc-dev/$PETSC_ARCH/shared/petsc/petscrules instead of petsc-dev/$PETSC_ARCH/shared/petscrules These things are still up in the air and will be adjusted as good ideas come in. Barry On Mon, 11 Jun 2007, Lisandro Dalcin wrote: > If one of the goals of the new build system is to be more symmetric > with the GNU model, in order to make life easier for packagers, so I > think the '$PETSC_PREFIX/conf' location should be renamed, perhaps to > '$PETSC_PREFIX/share/petsc'. I believe 'conf' is not a 'standard' > location. > > > >
more comments about new build system
I actually used conf because it is somewhat descriptive but won't miss up with other choices (like etc). Barry On Mon, 11 Jun 2007, Barry Smith wrote: > > Lisandro, > > Good point. etc was also suggested. Adding the petsc is > kind of ugly with the non-installed version, for example > > petsc-dev/$PETSC_ARCH/shared/petsc/petscrules > > instead of > > petsc-dev/$PETSC_ARCH/shared/petscrules > > These things are still up in the air and will be adjusted > as good ideas come in. > >Barry > > On Mon, 11 Jun 2007, Lisandro Dalcin wrote: > > > If one of the goals of the new build system is to be more symmetric > > with the GNU model, in order to make life easier for packagers, so I > > think the '$PETSC_PREFIX/conf' location should be renamed, perhaps to > > '$PETSC_PREFIX/share/petsc'. I believe 'conf' is not a 'standard' > > location. > > > > > > > > >
changes to PETSc-dev bmake system and library locations
On Mon, 11 Jun 2007, Lisandro Dalcin wrote:
> I think 'conf/variables' needs a bit more of work. I am not sure about
> what to do, the problem is here:
>
> PETSC_LIB_DIR = ${PETSC_DIR}/${PETSC_ARCH}/lib
> PETSC_INCLUDE = -I${PETSC_DIR}
> -I${PETSC_DIR}/${PETSC_ARCH}/include -I${PETSC_DIR}/include \
>${PACKAGES_INCLUDES} ${TAU_DEFS}
> ${TAU_INCLUDE} ${PETSC_BLASLAPACK_FLAGS}
>
>
> As you can see, there are references to $PESC_ARCH. So there are two
> potential problems using a 'install' version:
>
> 1.- If $PETSC_ARCH is not defined, some paths are of the form
> '/usr/local/petsc//lib'. Not sure is the double '//' could be
> problematic.
My working assumption was that Unix would always handle the // properly;
In 21 years of using Unix I've never seen this to be a problem, but then
I always learn new things.
>
> 2.- If $PETSC_ARCH is defined somewhere (user makefiles or even
> environment), bad paths will be generated,
This is true, if using PETSc makefiles and an "installed" PETSc,
things will be messed up. My assumption was that people who used
"installed" PETSc would not know or care about PETSC_ARCH
> and ${PETSC_LIB_DIR} is
> definitely broken.
Not sure what you mean here? In my limited tests setting
setenv PETSC_LIB_DIR /usr/local/lib for example,
worked fine.
Barry
>
> Is all this OK? Or my hg pull + hg update failed?
>
>
> On 6/11/07, Lisandro Dalcin wrote:
> > On 6/11/07, Satish Balay wrote:
> > > I should add that one motivation to support gnu/autoconf? 'make
> > > insall' model as closly as possible - is to make it easy for
> > > 'packagers' [deb,rpm etc..] to package PETSc
> >
> > OK, this make sense... I'll try this when I have some free time, I've
> > been playing a bit generating rpm's for Fedora.
> >
> >
> > [atleast the default
> > > config - whatever that means] and make it available for their
> > > respective distributions. Currently we only have only debian/freebsd
> > > packages - and nothing more.
> > >
> > > And I'm hoping that these packagers have their own models for
> > > installing multiple configs [via different prefix], so potentially
> > > multiple variants of PETSc config can be packaged [if they chose to do
> > > it].
> > >
> > > However I think the requirement of 'PETSC_DIR' might still be a minor
> > > hurdle for this mode. [the alternative would be providing compiler
> > > wrappers but thats a different discussion]
> > >
> > > Satish
> > >
> > >
> >
> >
> > --
> > 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
> >
>
>
>
changes to PETSc-dev bmake system and library locations
On Mon, 11 Jun 2007, Satish Balay wrote:
>
> However I think the requirement of 'PETSC_DIR' might still be a minor
> hurdle for this mode. [the alternative would be providing compiler
> wrappers but thats a different discussion]
>
> Satish
>
>
This will be fixed with my next push.
Also the /${PETSC_ARCH}/ --> // issue will be fixed.
Barry
