Re: Packaging problems with CM3

Two more comments to Henning's answer:

Henning Thielemann wrote:
>>This means that packages are more or less a construct in
>>quake outside of the Modula-3 language itself (there is no
>>indication in a module to which package it belongs or what
>>packages it im****ts).
> 
> Yes.
Conceptually the package structure is on another level than the
M3 language (and can as well be used for others languages), but in
CM3 the builder is integrated with the actual M3 compiler and the
quake interpreter.

>>On the other hand the CM3 source distribution inserts
>>another structuring layer for those packages. E.g. the
>>"libm3" and "m3core" packages are put into a superpackage
>>called "m3-libs".  This also reflects in the directory
>>structure where package "libm3" has path
>>"pkg/m3-libs/libm3".
> 
> 
> Unfortunately the directory structure of the project's sources will be
> flattened on installation (you know '****pping' :-). Library packages
often
> contain a directory (a sub-package!) with name 'test'. This is normally
> not ****pped as this would cause name conflicts. The philosophy behind
> this is that test programs need not to be installed for regular usage.
Yes, the directory hierarchies of the PM3 and CM3 distribution
are lost in the installed packages. Actually, what I would like
was a package system that is able to im****t from and ****p to
several pools of packages (as we have implemented in pkgm from
ComPact some years ago). Thus pools can be dedicated to certain
purposes or groups of users. Package im****ts could be satisfied from
a pool path (try all the pools in order and take the first package
found) while ****pping would need either an explicit destination or
some kind of name binding for abbreviation. It's some work do implement
this in CM3 though due to the tight integration of quake and the m3
builder.

Olaf