petsc-dev directory structure questions

[Satish Balay]

On Thu, 13 Dec 2007, Barry Smith wrote:

> 
> On Dec 13, 2007, at 5:07 PM, Satish Balay wrote:
> 
> > 
> > For one, I think conf/configure.py should be ./configure.py
> 
>   How come this wasn't done originally or hasn't been changed to
> this already?

I think the reason config/configure.py was chosen is for symmmetry
with ./config/linux-gnu.py etc.. with user invocation.

[also ./config/linux-gnu.py etc scripts can easily use
config/configure.py if both scripts are in the same location]

So the initial design thought was: [form user interface side]
config/configure.py is equivalent to ./configure from autoconf with
the additional benefit of site specific scripts feature
[config/linux-gnu.py, config/solaris-2.9.py etc..]. Also these
additional scripts don't clutter PETSC_DIR.

But with moving BuildSystem into config, this location now has a
different meaning. [intially config/configure.py was equivalent to
user main code - aka ex1.c, whereas PETSC_DIR/python was equvalent to
libraries. Now config is its equvalent to a single application with a
hundred sourcefiles]

> > And conf and config are 2 different things - so they should be in
> > separate locations. merging them doesn't make sense to me. The primary
> > issue I see is the names "conf" and "config" are extremely close to
> > each other.
> 
>   Exactly, so how the heck is anyone suppose to know what is in either
> one of them?

One is source for configure.py , the other is input for generated
config/make files. So bmake [or default-make-config] was a more
descriptive name. But we don't want such superflus names with
prefix/make-install stuff.

We couldn't find the correct name for 'conf' in the make-install
world, so the name 'conf'. was chosen.

> > One option is to move config to src/config [this would work well with
> > ./configure.py]
> 
>   config stuff is not source code so cannot go in there.

To me, they are source for configure.py so I see no problem with this
move. We already have src/docs for web sources.

This move [with the cost of splitting up symmetry with
config/configure.py & config/linux-gnu.py] is better than dumping conf
in config. Sticking with the current conf & config is more prefereable
to the above 2 changes. [With BulidSystem move, 'config' already feels
cluttered, but I'm ok with it]



Wrt using 'python' dir name I think we had the following thoughts when
this was done initially.

- we already had language sepcific dir src/fortran, at the toplevel in
  PETSc sources. This was before splitting this into ftn-auto,
  ftn-custom etc. We still have src/fortran for some things [perhaps
  this should be completely merged into src/sys now?]. And the plan
  was to have python interfaces for PETSc generated similar to fortran
  interfaces?

- And then with python, with dirnames significant in the namespace
  and all, and the initial configre dependeng upon PYTHONPATH, it made
  sense to identify such dirs that go into PYTHONPATH with a sensible
  name [and also identify the toplevel dir where namespaces begin].

Some of these issues were fixed since then, [no need for PYTHONPATH],
no python interfaces dispersed in src, [but the separation between
application code - aka configure.py, and the python-modules it uses
was kept].

Satish