Re: src/ directory re-org

[Rik]

On 08/01/2012 09:42 AM, address@hidden wrote:
> Message: 2
> Date: Wed, 1 Aug 2012 12:27:44 -0400
> From: "John W. Eaton" <address@hidden>
> To: octave maintainers mailing list <address@hidden>
> Subject: more source directory reorganization
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> I pushed a few more source reorganization changes to savannah.
>
> You will need to re-run ./autogen.sh in your source tree after
> updating.
>
> If you don't want to have old files left over in your build tree, you
> can remove the src directory before running configure.
>
> If you are building in the source tree, you obviously can't take that
> simple step and will instead have to do something like make
> maintainer-clean in the src directory before updating the sources.
> But that also raises the question of why are you building in the
> source tree instead of using a separate directory for the build?
>
> The changes are:
>
>   * To be more consistent with the naming of the new src/corefcn
>     directory, src/DLD-FUNCTIONS is now src/dldfcn.
>
>   * The following files, which only define DEFUN functions and do not
>     export any functions have been moved to the corefcn directory:
>
>       bitfcns.cc  mappers.cc  sparse.cc  strfns.cc  syscalls.cc
>
>   * Since there should be no header files in the corefcn directory
>     (the only external functions in those files should be defined with
>     DEFUN) the -Icorefcn and -I$(srcdir)/corefcn flags have been
>     removed from the compiler flags in src/Makefile.am.
>
> There are a few more files in the src directory that contain a lot of
> DEFUN functions, but they also contain some non-DEFUN functions that
> are exported.  I'm thinking that we should split the DEFUN functions
> out from these other external functions and move them to corefcn.
> Ideally, corefcn would just contain DEFUN wrappers and the code that
> provides the functionality would be available to other C++ code
> without needing to call a DEFUN function.  For example,
> src/corefcn/time.cc is a good example of how things should be done,
> and src/corefcn/qz.cc is an example of what NOT to do.  Instead of
> doing the computations in the DEFUN, there should be a separate class
> (in liboctave, if possible) that implements the computation for the qz
> function and qz.cc should just decode arguments and use the class.
>
> Comments?
John,

There are still a few more changes I would make.  Running 'ls *.h *.cc | wc
-l' in the src/ directory returns 167 which is still a just barely
comprehensible menagerie for us mere mortals.  (You have demi-god status
and are excepted from this).  I would continue to divide the code up along
logical lines.  For example, I think the lexer and parser code should sit
with the other parser-related code in the parse-tree directory.  I also
think the various options setting code, like LSODE-opts.cc, should reside
in corefcn/.

I think the reasoning to divide up core library code from DEFUN code is
good.  In addition, I would like to make one more division between
interpreter-related functions (load, save, dbstop, etc.) and math-related
functions (pinv, chol, etc.).  I find this grouping easier to understand
than one based on whether or not there is a header file and I think it will
help prevent corefcn from becoming too large and ungainly.  So, my proposed
structure would be:

parse-tree/
  lexer, parser, and all parse-tree pt* code
octave-value/
  All octave_value related code ov*
operators/
  All operator related code
template-inst/
  Not sure about this one
core-interp/ (Name open to change)
  C++ code in liboctinterp which is called directly rather than through a
DEFUN.
interpfcn/ (Name open to change)
  DEFUN C++ code for interpreter functions such as load, save, dbstop.
corefcn/
  DEFUN C++ code for mathematical core functions such as pinv, chol.
dldfcn/
  Dynamically loaded functions

src/
  Remaining code files, mostly for octave itself such as main.c, octave.cc.
  Would also potentially contain a few scripts like mkbuiltins.

--Rik