[Top][All Lists]

[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.


reply via email to

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