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