petsc-dev directory structure questions (fwd)

[Satish Balay]

resending by reformatting ^config

Satish


---------- Forwarded message ----------
Date: Fri, 14 Dec 2007 09:31:52 -0600 (CST)
From: Satish Balay <balay at mcs.anl.gov>
To: petsc-dev at mcs.anl.gov
Subject: Re: petsc-dev directory structure questions

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