1,852
edits
Projects: Difference between revisions
Jump to navigation
Jump to search
→Packaging: Merge GSoC Octave Package management.
(→Numerical: Move projects from GSoC page.) |
(→Packaging: Merge GSoC Octave Package management.) |
||
| Line 464: | Line 464: | ||
* Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance. | * Develop a performance benchmark for Octave (interpreter, load/save, plotting, etc., but not simply tests of underlying libraries such as BLAS or LAPACK). This benchmark could be run periodically to make sure that changes during development do not introduce regressions in performance. | ||
= | = Octave Package management = | ||
[[Packages]] are extensions for Octave. To get those extension to work with Octave, there is a single function, {{manual|pkg}}, which does pretty much everything. | |||
This function has a few limitations which are hard to implement with the current codebase, and will most likely require a full rewrite. | |||
A major step forward for a rewritten package manager is the [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project] by Andrew Janke. | |||
The planned improvements are: | |||
* install and update from repositories (hg and git) | |||
* automatic handling of dependencies | |||
* easily load, update or check specific package versions | |||
* management of tests and demos in C++ sources of packages | |||
* more flexibility on dependencies, e.g., dependent on specific Octave build options or being dependent in one of multiple packages | |||
* support for multiple version packages | |||
* support for multiple Octave installs | |||
* support for system-wide and user installed packages | |||
* testing packages (<code>pkg test <package-name></code>) | |||
* improved metadata acquisition (<code>pkg list -forge</code>) from https://octave.sourceforge.io/ | |||
* create a system that allows packages to deprecate functions as in core. Possibilities are: | * create a system that allows packages to deprecate functions as in core. Possibilities are: | ||
| Line 477: | Line 494: | ||
** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute? | ** subdirectories with makefiles and top level make command of: cd <subdir> && ${MAKE}... ok as a substitute? | ||
* make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?) | * make pkg able to supply extra configure and make flags, useful for distributions, including -j for make (pkg now passes --jobs=N automatically, CFLAGS and CXXFLAGS environment variables are already respected, what's missing?) | ||
The main objective of this project is to make {{manual|pkg}} more user friendly and to make it a tool to foster third party participation in Octave. | |||
However, the current {{manual|pkg}} also performs some maintenance functions which it probably should not. | |||
Instead a package for developers should be created with such tools. | |||
To do this enhancement effectively, a refactoring of the current {{codeline|pkg}} code will be needed (see [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project]). | |||
Many of these problems have been solved in other languages. | |||
Familiarity with how other languages handle this problem will be useful to come up with elegant solutions. | |||
In some cases, there are standards to follow. | |||
For example, there are specifications published by freedesktop.org about where files should go ([http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html base directory spec]), and Windows seems to have its own standards. | |||
See bugs {{bug|36477}} and {{bug|40444}} for more details. | |||
In addition, package names may start to collide very easily. | |||
One horrible way to work around this by is choosing increasingly complex package names that give no hint on the package purpose. | |||
An option is providing an "Authority" category like Perl 6 does. | |||
Nested packages is also an easy way to provide packages for specialized subjects (think {{codeline|image::morphology}}). | |||
A new {{manual|pkg}} would think all this things now, or allow their implementation at a later time. | |||
Read the [[OEP:pkg|unfinished plan]] for more details. | |||
=Preferences= | =Preferences= | ||