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