[petsc-dev] no module named cmakegen
Matthew Knepley
knepley at gmail.com
Mon Aug 23 22:18:35 CDT 2010
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-0003.html>
More information about the petsc-dev
mailing list