[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Package system
From: |
Paul Kienzle |
Subject: |
Re: Package system |
Date: |
Sat, 22 Oct 2005 16:59:44 -0400 |
On Oct 21, 2005, at 11:56 AM, Søren Hauberg wrote:
I just updated the code to include some documentation. You can get it
from http://hauberg.org/octave-package/package-0.2.1.tgz
Some packaging issues that occur in octave-forge:
- main/audio creates a binary that should be installed in the helper
binary directory. I put them into octave_config_info
("localverarchlibdir").
- main/audio/data has a sample wav file which I install into the data
path for the package. In this case, I simply use the package path
itself and find from the script using file_in_loadpath('file.wav').
- main/comm/doc has texinfo documentation which should be built and
installed in the usual texinfo places. Pure documentation packages
such as doc/coda are also possible.
- main/control is an example of a single function package intended to
extend an existing package. Does it need its own directory? Or can we
request that it be installed in the same directory as the control
package, while updating the list of functions reported by "help
control"?
- extra/engine has libraries and headers that are needed by other
programs. They should be installed in /usr/include and /usr/lib or
/usr/local/include and /usr/local/lib.
- extra/mex and main/fixed have libraries and headers that need to be
available for compiling other oct-files. They should be installed
along side the octave libraries and headers.
- extra/graceplot introduces alternatives. The package system should
support this in some way so that the user can toggle at run time
between graceplot and gnuplot. extra/nan, which replaces some standard
octave commands with alternatives which ignore NaN, could also be
handled with alternatives.
- extra/perl and extra/soctcl are packages for other languages so they
are not our problem ;-)
- extra/MacOSX and extra/Windows are system dependent. It's the user's
problem to decide whether or not to install them.
- configure.base contains configure information useful to a number of
packages. Much of this is available in modern versions of octave,
through system commands such as octave-config and through the octave
command octave_config_info. Other things such as the flags to the cp
command, and the details of txi->info conversion should be part of the
packaging system.
- anticipate translated help files for multiple languages as part of
the package.
- I didn't see where you created the PKG_ADD file by extracting PKG_ADD
lines from the individual m-files.
Some more general comments:
- package version should be available at run time. Currently I have
OCTAVE_FORGE_VERSION.m for all the packages. Maybe a version
subcommand on the pkg command is the best way to handle this?
- we should be able to build and test the packages before installing
them.
- we should note whenever a installed command shadows an existing
command.
- in octave forge most tests are embedded in the files themselves and
discovered with admin/mktests.sh. The tests should be installed along
with the functions so that the user can see at run time what tests the
function is supposed to pass. Also some tests are actually demo blocks
which are part of the documentation of the function. Some tests are
embedded in C++ files. These will need to be extracted before
installing. In retrospect tests should perhaps be in separate .test
files in both cases, and maybe separate .demo files for the demos.
- for windows systems which may not have the compilers installed, we
may want to support binary packages. This would be advised for OS X
systems as well, where tracking down and installing third party
libraries prior to installing the package would be a pain.
- the packaging system should be available and useful for matlab as
well. That way authors of packages such as wavelab will have less work
to do to support octave. For example, if you automatically generate
the contents.m from INDEX and admin/make_index the contents file will
be easier to maintain and it is a win for them. Similarly, we should
Do the Right Thing with a usual matlab tarball which has contents.m
rather than COPYING DESCRIPTION and INDEX files.
Paul
- Re: Package system, (continued)
- Re: Package system, Søren Hauberg, 2005/10/21
- Re: Package system, John W. Eaton, 2005/10/21
- Re: Package system, Søren Hauberg, 2005/10/21
- Re: Package system, John W. Eaton, 2005/10/21
- Re: Package system, Søren Hauberg, 2005/10/21
- Re: Package system, Søren Hauberg, 2005/10/22
- Re: Package system, Paul Kienzle, 2005/10/22
- Re: Package system, Paul Kienzle, 2005/10/22
Re: Package system,
Paul Kienzle <=
RE: Package system, Hall, Benjamin, 2005/10/21