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

[Matthew Knepley]

On Mon, Sep 21, 2020 at 3:05 AM Barry Smith <bsmith at petsc.dev> 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.
>

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.

   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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20200921/763e0488/attachment.html>