[petsc-dev] no module named cmakegen

[Jed Brown]

On Mon, 23 Aug 2010 16:18:27 -0500 (CDT), Satish Balay <balay at mcs.anl.gov> wrote:
> Well currently configure is to be invoked in PETSC_DIR - and the py scripts
> generally use relative paths to find each other. For eg: config/configure.py has:
> 
>   # Should be run from the toplevel
>   configDir = os.path.abspath('config')
>   bsDir     = os.path.join(configDir, 'BuildSystem')

Right, and self.petscdir is set regardless of whether the environment
variable PETSC_DIR has been set.  The trouble comes when you invoke a
script (that could be run stand-alone, even if that is advanced usage).
Even if you didn't mind requiring that PWD be chosen carefully before
calling the maintenance script (which I find ugly), we still don't want
to copy all the environment checks and error handling from configure.py,
but we can't find *any* PETSc modules without knowing PETSC_DIR or using
the relative path hacks.

In this case, the script has to be able to "import script" before the
PETScMaker type can be declared.  Maybe the right thing to do is to move
the whole class definition into cmakeboot.main() which acquires petscdir
as an explicit argument, and can thus set things up correctly.

Any comments/suggestions on what I currently have in cmakeboot.py?

  def main(petscdir, petscarch, argDB=None, framework=None, logPrint=printFunction, args=[]):
    # This can be called as a stand-alone program, or by importing it from
    # python.  The latter functionality is needed because argDB does not
    # get written until the very end of configure, but we want to run this
    # automatically during configure (if CMake is available).
    #
    # Strangely, we can't store logPrint in the PETScMaker because
    # (somewhere) it creeps into framework (which I don't want to modify)
    # and makes the result unpickleable.  This is not a problem when run
    # as a standalone program (because the database is read-only), but is
    # not okay when called from configure.
    PETScMaker(petscdir,petscarch,argDB,framework).cmakeboot(args,logPrint)

Note that cmakeboot.py can be called independently after configure, it
does not modify argDB at all, but I have it running during configure
just so that users of the cmake build don't have any extra steps to
remember (just configure as usual, the run make from the build
directory).

Jed