21
edits
(Update mentor name) |
AndrewJanke (talk | contribs) m (Fix configure invocation) |
||
(2 intermediate revisions by one other user not shown) | |||
Line 38: | Line 38: | ||
*: [http://en.wikipedia.org/wiki/GNU_build_system The GNU build system] is used to build Octave. | *: [http://en.wikipedia.org/wiki/GNU_build_system The GNU build system] is used to build Octave. | ||
*: While you generally don't need to understand too much unless you actually want to change how Octave is built, you should be able to understand enough to get a general idea of how to build Octave. | *: While you generally don't need to understand too much unless you actually want to change how Octave is built, you should be able to understand enough to get a general idea of how to build Octave. | ||
*: If you've ever done a {{Codeline|configure && make && make install}} series of commands, you have already used the GNU build system. | *: If you've ever done a {{Codeline|./configure && make && make install}} series of commands, you have already used the GNU build system. | ||
*: '''You must demonstrate that you are able to build the development version of Octave from sources before the application deadline.''' Linux is arguably the easiest system to work on. Instructions: | *: '''You must demonstrate that you are able to build the development version of Octave from sources before the application deadline.''' Linux is arguably the easiest system to work on. Instructions: | ||
*:* [[Building]] | *:* [[Building]] | ||
Line 342: | Line 342: | ||
=== Octave Package management === | === Octave Package management === | ||
Octave | [[Packages]] are extensions for Octave, that are mainly maintained by the [[Octave Forge]] community. | ||
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: | The planned improvements (see also {{bug|39479}}) are: | ||
* install and update from repositories (hg and git) | * install and update from repositories (hg and git) | ||
* automatic handling of dependencies | * automatic handling of dependencies | ||
Line 355: | Line 357: | ||
* support for multiple Octave installs | * support for multiple Octave installs | ||
* support for system-wide and user installed packages | * 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/ | |||
The main objective of this project is to make {{ | 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. | 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 workaround this by is choosing increasingly complex package names that give no hint on the package purpose. | |||
In addition, package names may start to collide very easily. One horrible way to workaround this by is choosing increasingly complex package names that give no hint on the package purpose. A much better is 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 {{ | A much better is 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. | |||
* '''Minimum requirements''' | * '''Minimum requirements''' | ||
: Ability to read and write Octave code, experience with Octave packages, and understanding of the basics of autotools. The most important skill is software design. | : Ability to read and write Octave code, experience with Octave packages, and understanding of the basics of autotools. The most important skill is software design. | ||
* '''Difficulty''' | * '''Difficulty''' | ||
: | : Medium. | ||
* '''Mentor''' | * '''Mentor''' | ||
: [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps | : [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps |
edits