Maybe you have an old BuildSystem? Matt
On 6/11/07, Todd Munson <tmunson at mcs.anl.gov> 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 60439 http://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 <bsmith at mcs.anl.gov> 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/ > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > -- 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