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

[Satish Balay]

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.

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.

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
> 
> 
>