octave-maintainers
[Top][All Lists]
Advanced

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

more source directory reorganization


From: John W. Eaton
Subject: more source directory reorganization
Date: Wed, 1 Aug 2012 12:27:44 -0400

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?

jwe


reply via email to

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