On Mon, 23 Aug 2010 17:21:52 -0500 (CDT), Satish Balay <balay at mcs.anl.gov> wrote: > On Mon, 23 Aug 2010, Satish Balay wrote: > > > Now that there are more and more standalone scripts - perhaps we need > > a better consistant way to handle this - but I don't know what that > > is.. > > mercurial way is to have 'hg' be the frontend script to all commands. > i.e no invocation of individual scripts .. > > Perhaps we should adopt that?
Interesting idea. Have one top-level "petscconf" with subcommands to configure, build (via make, builder.py, cmake), interrogate for linking options, etc. Matt, it doesn't require modification of PYTHONPATH since you would use the path in which the executable resides (may or may not be "installed"). You wouldn't normally put the executable in your path, instead run /path/to/installed-or-not/petsc-x.y/petscconf subcommand --options The only thing you couldn't do is to move petscconf to some other location (independent of the rest of the PETSc tree). This begs the question of how PETSC_ARCH would be handled. Either there would be separate top-level script for ARCH-specific and ARCH-agnostic functionality, or PETSC_ARCH would need to remain an environment or otherwise specified configuration variable. Jed