[petsc-dev] Installation namespaces

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>> On Dec 25, 2016, at 6:43 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>> Almost nothing we install to $prefix/bin is namespaced, let alone
>> required to use PETSc.  I think we should remove most of it from prefix
>> installs and namespace everything that is truly needed.
>> 
>> And we really need to stop installing the ridiculous bin/*
>> subdirectories (especially bin/maint).  Nobody uses directories in /bin
>> and most of the stuff in bin/maint is not relevant to prefix installs.
>> Most of those directories should either be not installed or go in
>> lib/petsc/.
>
>    Agreed. I am surprised it is dumping all this stuff/crap.
>
> $ ls /Users/barrysmith/petsc-install/bin/
> FASTMathInstaller.py   configVars.py          petsc_gen_xdmf.py      petscnagupgrade.pyc    sendToJenkins          urlget.py
> PetscBinaryIO.py       maint                  petscdiff              petscrun               taucc.py               win32fe
> PetscBinaryIO_tests.py parseargs.py           petsc_gen_xdmf.py      popup                  uncrustify.cfg
> TOPSGenerator.py       petsc-mpiexec.uni      petscmpiexec           portabilitycheck.py    update.py
> adiforfix.py           petsc_conf.py          petscnagupgrade.py     saws                   urlget
>
>> 
>
> The only things worth keeping IMHO are petscdiff,  PetscBinaryIO.py   and petsc_gen_xdmf.py but the later two are Python, do they belong somewhere else anyways since they are python.

It seems to me that we should use distutils for python installation.

  https://docs.python.org/2/distutils/setupscript.html

There is a question of which Python to use since PetscBinaryIO.py should
work with python3.

> BTW: some stuff in bin IMHO more properly belongs in maint.   The saws directory is PETSc stuff based on saws so maybe should be namespaced with PETSc (and no subdirectory). 

Agreed.  We could also replace the bash scripts with subcommands of a
single Python executable (fewer dependencies and less intrusive).

>> I also have a complaint about stale install trees.  I had an old
>> PETSC_ARCH (built long ago).  I updated my repository to today's
>> 'master' and did
>> 
>>  make reconfigure gnumake install
>> 
>> and it installed (to a just-cleaned prefix):
>> 
>>  petsc-mpich-basic-prefix/lib/modules
>>  petsc-mpich-basic-prefix/lib/modules/3.4.2
>>  petsc-mpich-basic-prefix/lib/modules/3.4.3
>> 
>> I believe this is because we copy all of PETSC_ARCH/lib (those files
>> existed a couple years ago when this arch was first built).  I consider
>> this to be a bug, though it feels hard to fix in the current
>> environment.  I think it would be better to move our installs to a
>> whitelist scheme (perhaps with globbing) rather than bulk copy.
>
>     The installation is all handled with one nice python script which can be easily edited to get the effects you want :-)

Yes, but inlining a whitelist to install.py would be a maintenance
burden.  (How bad?)  We could have configure and/or make maintain it,
but that's nontrivial development (not isolated to install.py).
Alternatively, we could have reconfigure do more automatic cleaning.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20161226/778c5ae3/attachment.sig>