Re: Proposal: An OOC Package Tool

[Stewart Greenhill <greenhil@murdoch.edu.au>]

At 05:47 PM 5/4/99 +0200, Michael van Acken wrote:

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

This is an interesting proposal which should simplify the maintenance of
software packages. I don't know why this sort of thing is not already in
one of the existing Oberon systems.

[...]

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

As with "make" it ought to be possible to consider the tools themselves as
packages. For example, a package may require a certain version of the
compiler, libtool, etc. Where a tool depends only on O2 source, it is
probably a simple matter for the tool to be fetched and compiled. I'm
thinking in particular of immature tools (like h2o), where functionality
might vary greatly between releases.

[...]

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

Blackbox has a subsystem naming scheme that prefixes module names with
strings. Sub-systems are stored in sub-directories (with the same name as
the prefix) of the Oberon root, and sub-directories within a sub-system
have particular uses. Eg.

  Doc   - documentation
  Rsrc  - resources (eg. dialogs, forms)
  Mod   - source code
  Sym   - symbol files
  Code  - object files

The compiler / run-time system understands the meanings of the directories.
Thus, if you get a TRAP in module SysFoo, the debugger looks in Sys/Mod to
find the source code to module Foo. It seems to work fairly well, but I
think the proposed scheme is probably more useful.

- Stewart