[petsc-dev] Should everything in include be a symbolic link in the git repository?

[Satish Balay]

A couple of notes:

- not a good idea to make this change  for this release [even if acceptable to all developers]

- I'm not sure 'eliminating makefiles' should be the goal. It might
  not make a difference to most users [well it can break some
  externalpckages - that look for files - and not links etc] - but it will
  affect other developers wrt whatever new system is in place

- I understood that one of the desired features was:
 * work away in some source [or example] dir.
 * run make in this dir - to update libraries - or build examples [without having to cd to PETSC_DIR to run make]

eliminating makefiles will remove these features. [and its not yet clear to me what features are gained by it - and if that's net positive or not. Sure one can always find some benefit and ignore or trivialize the negatives]

Satish

On Mon, 21 Sep 2020, Barry Smith wrote:

> 
> 
> > On Sep 20, 2020, at 11:54 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> > 
> > For one - the makefiles are primarily used for docs - and the related issue with includes is the binding from MANSEC and SUBMANSEC to the corresponding sourcefiles.
> > 
> > If the makefiles are removed - and alternate mechanism is need for this [and all other doc targets that use makefiles]. I don't know what this replacement system is - and if that system will be better or more complex then the current system.
> 
>   I only see to ways of managing things like MANSEC (which is maybe only for docs but tells each source file what component it is associated with so is abstractly more than docs). Either we do it based on directories or every single source file has inside it this information. I think a hybrid system where sometimes it is inside the file and sometimes it is based on the directories is not desirable from a maintenance perspective. 
> 
>   But if we think of source files as possibly living in multiple "components" simultaneously (like code for a viewer and for HDF5) then as we talked about recently maybe all this information just needs to be imbedded in the file.
> 
> > 
> > And wrt moving include files [I'm not sure if this alternate doc system really requires this move of include files, but maybe it helps in separating the modules better?] - we shouldn't use PETSC_DIR/include anymore
> > 
> > They should go into PETSC_DIR/PETSC_ARCH/include (at configure step) - and be in sync with --prefix organization.
> 
>   Maybe, one advantage of this approach is exactly those links for the configuration are set and not all of them (for example includes specific to external packages like hdf5) but I am not sure this is important enough to be a better system than just having git repository links for all of them. For application code portability there may be something said for always having all the includes visible to user code, even those not usable so users don't need to protect "optional" PETSc includes with ugly ifdef.
> 
>   Barry
> 
> 
> > 
> > Satish
> > 
> > On Sun, 20 Sep 2020, Barry Smith wrote:
> > 
> >> 
> >>  The include directory is special because it contains source code from all components of PETSc but artificially collected together in a single directory tree because the C/C++/Fortran compilers like it this way to not require hundreds of -I and for distribution without the source.
> >> 
> >>  Should the PETSc git repository be reorganized where the include files in the include directory tree are actually in the appropriate subdirectories of src/ and symbolic links are used in the include directory tree to point to their locations in  src/ ?
> >> 
> >>  In the tarball the include files would be actually in the include directory when the tarball is generated.
> >> 
> >>  --with-prefix installs will, of course, copy the include files over so having them in src does not matter.
> >> 
> >>  Does git handle symbolic links nice enough to support this.
> >> 
> >>  The reason to make the change is as we move away from having makefiles in all the directories with lists of files we need to know the "home component" of all the files in the include tree and the natural way to know the home is to have the true files in the appropriate src subdirectory.
> >> 
> >>  Barry
> >> 
> >> 
> >> 
> > 
>