Proposal: An OOC Package Tool

[Michael van Acken <acken@vanacken.do.uunet.de>]

Oberon was designed as an extensible from the very beginning.  But
extending an installation by adding new modules and programms has
always been a very low-level operation.  This process can be made much
more user friendly.  Here is an outline of an OOC Package Tool,
tentatively called "oopt" for now.  I would like to know if anyone
supports the idea of such a beast.

--------

With "package" I mean a collection of source code.  Binary packages
are not supported.  An example for this are Perl modules, available
from any CPAN site near you.

Packages are associated with meta information.  A package lists the
names of other packages it depends on, or which it suggests to install
first.  Additionally, after installing a package, it is sometimes
necessary to provide information to the compiler how to use it,
e.g. by listing external libraries that need to be linked in when
using the package.

Another kind of meta information is the package's documentation.  The
installation process should be able to extract the documentation and
make it accessible in a local repository, e.g. as a set of HTML or
info pages.

The interface of a package is versioned, e.g. using the libtool
numbering scheme.  Versioning is based on the binary interface of the
package's modules.  E.g., adding a record field to an exported type
declaration results in a new package interface, because it could
change the offsets of record fields and the record's size.

Adding a package to a system should be simply a matter of adding a few
files to the local OOC installation.  Currently a new package means to
hack the compiler's configuration file to add any necessary pragma and
option variables, and maybe to add new search paths.  Needless to say,
this practice makes it hard for packaged distributions like Debian to
properly handle OOC add-ons.

Usually there are two kinds of packages: system dependent, low-level
packages that provide access to external libraries (libX, libwww,
etc.) and packages that are pure Oberon-2 modules.  The latter depend
only on the compiler and the package mechanism for building and
installation, the former come with their own installation magic (i.e.,
with configure).  A package can state that it depends on external
programs or libraries, but must do its own magic to check for them.
E.g., if the user wants to install package "libwww" (which is just a
set of O2 bindings to the external library), he must get the library
and install it first, before installing the OOC package.

Packages are distributed over the net, either from a central
repository (like CPAN) or with a more distributed structure.  Any
package can be downloaded and installed directly.  [I intend to use
the W3C's libwww for the download part.]  Installation of a package
`foo' should be take a single command: "oopt install foo".  This
downloads package `foo', all the packages `foo' depends on, and
(optionally) all the packages it suggest, and installs all of them.
Similar to Debian's apt-get, an upgrade of installed modules can be
performed by issuing the command "oopt update" (get up to date package
information) and "oopt upgrade" (to perform the actual upgrade of old
packages).

--------

Oberon-2's relationship to packages is, simply put, non existent.  The
single flat namespace for modules sucks.  It is strange that a system
designed for extensibility has no means to keep the complexity of
managing extensions at an acceptable level.  Prefixing all modules of
a package with a unique string is a step in the right direction, but
at the same time it's only a half-hearted attempt.  There is still
just a flat name space, and there is no way to associate packages with
meta information as long as the compiler does not know anything about
packages.

To pass package information to the compiler, I propose a minimalistic
change to the Oberon-2 IMPORT statement.  In addition to the import
clause

  ident [":=" ident]

there is a second variant, 

  ident := ident {"." ident}

to access a module from a package.  A module `bar' from package `foo'
would be imported as "IMPORT boo := foo.bar".  The statement "IMPORT
foo.bar" is not allowed, which means that there is no need to change
the rule for "Qualident".  The rest can be handled by the compiler.

To turn "package aware" source code into standard O2 source code, it
can be passed through oocn for some simple IMPORT rewriting.


There.  Let the flame wars begin.

-- mva