> On Sep 21, 2020, at 5:17 AM, Matthew Knepley <knep...@gmail.com> wrote: > > On Mon, Sep 21, 2020 at 3:05 AM Barry Smith <bsm...@petsc.dev > <mailto:bsm...@petsc.dev>> wrote: > > > > On Sep 20, 2020, at 11:54 PM, Satish Balay <ba...@mcs.anl.gov > > <mailto:ba...@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. > > I do not think the headers are worth moving. If we improve the source > discipline a little, they can be largely autogenerated. We now know all the > declarations that > should be public. There is some other stuff in headers, but very little, and > that probably benefits from being in a specific place like include.
There is actually a great deal of source code in the headers. Definitions of all the enum, data structures (in petsc/private), many macros and some in-line functions. It is not just function prototypes. Barry > > Matt > > 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 > >> > >> > >> > > > > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
