On Mon, Aug 23, 2010 at 10:38 PM, Jed Brown <jed at 59a2.org> wrote: > 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 .. > > Okay, I understand Satish. This sounds good.
> > 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. I am fine with PETSC_ARCH being a script parameter, and having a default. Matt > > Jed -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100824/a31c56c5/attachment.html>