octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: src/ directory re-org


From: John W. Eaton
Subject: Re: src/ directory re-org
Date: Thu, 2 Aug 2012 18:42:56 -0400

On  2-Aug-2012, Rik wrote:

| On 08/02/2012 12:40 PM, John W. Eaton wrote:
| 
| >
| > Would corefcn, interpfcn, and dldfcn contain any header files to
| > export functions that are called directly?
| I think we will need to wait and see how things evolve.  The dldfcn/
| directory contains just one header file, oct-qhull.h, but that is for its
| own use and not for exporting functions.  This leads me to believe there it
| at least a possibility that these three directories would not need to
| export functions.

OK.

| > If we split files apart, what should we do about copyright info when
| > there are multiple people claiming copyright?
| I think the safest thing is to assign copyright from all authors to both
| split files.  If there was a practical way of tracing authorship then we
| could extend copyright only on the portions that a given author had
| written.  In the print world the analogy might be to an anthology of short
| stories.  In that case, each chapter bears its own copyright and if one
| were to take multiple chapters it would be fairly straightforward to just
| list the authors on the now reduced collection of stories.  In this case,
| since I doubt we can disentangle which stanzas of code were written by
| which particular author, I think we must list all authors as having
| contributed to the new source file.

Yes, I agree that this is probably the best we can do.

| I also think this sort of change would be better as a second phase.  The
| first phase I see is just to deal the whole files out between
| subdirectories.  And after that we can slowly decide whether a file belongs
| in a different directory or whether it should be split into multiple files.

I'm OK with going ahead with the reorganization even if that means
that we need to add -IDIR -I$(DIR) to the list of CPP flags in the
src/Makefile for each of these new subdirectories, with the goal being
to eventually make some of the directories contain only DEFUN
functions.  I think the added structure is worth more than the clutter
of extra flags in the compiler commands.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]