I have put together some control files for octaveSF so that the entire
tree can be
configured, compiled and built automatically. In the process, I have
restructured
the tree. See:
http://users.powernet.co.uk/kienzle/octaveSF-2001.09.21.tar.gz (750
kB)
If there are no objections, I will ask the people at sourceforge to
replace the
current CVS tree with tree given in this tarball.
Dirk, you and Raphael will have to sort out the Debian packaging issues.
Particularly, nonfree/gpc has package control information in it
already. Perhaps
anything that octave-SF.deb does not include could be packaged
separately?
Note that extra/tk_octave needs octave compiled with -lpthread, so you
will need to change how you build the octave package itself if you are
going
to package it. AFAIK, it will not hurt octave in any way to compile it
with pthreads,
but I haven't run the test suite or tried any timing tests.
Anyone want to try their hand at writing a generic Octave package
installer?
instoct.sh.in is a start, but it would be nice if the path details were
also substituted
by ./configure so that the user could type:
octpackage build <package-name>
compile anything that needs compiling
octpackage test <package-name>
run all the tests in the package
octpackage install <package-name>
build and test the package if you haven't already done so
copy m-files, oct-files, data, bin, libs, manpages, etc. to
the users path
update ~/.octavepackagerc with any initialization that needs
to be done
octpackage installsite <package-name>
like install, but install into the site paths rather than
the user paths.
octpackage clean <package-name>
remove any files that have been built
And in octave, type
package <package-name>
list the contents of the package, preferably categorized
with a description
of each category and a one-line description of each
function.
The package documentation file could have a standard name like 00Index,
which
would be installed to something like <package-name>.index in the package
directory. Then file_in_load_path will be able to fetch it for you.
Ideally, this
file would contain the category descriptions, with a tag such as
@category-name@
where the functions for that category are to be listed, and each
function file
would have something like the following:
##CAT: <list of categories this function belongs to>
##DESC: <one line description of the function>
If you are really ambitious, the "See also" lines in the function
documentation
could be generated automatically to contain other functions in the
category,
though this might not be enough.
|
