On Mon, 5 Jan 2004, Thomas Tensi wrote:
> I'm currently installing the CM3 distribution in a Windows
> environment and have severe problems with the packaging
> philosophy of Modula-3.
Each package represents a library or a single program. I liked to put
large amounts of code into one package to benefit from the nice build
mechanism, but I'm afraid this is not the intended use especially because
dynamically linked libraries become quite big this way.
> As far as I understand M3 modules belonging together are
> grouped in the same directory residing under "pkg" in the
> file system. This directory represents a "package".
> E.g. the core system modules of Modula-3 reside in
> "pkg/m3core" and below.
The 'pkg' directory contains the _installed_ files. Modula 3's build
system distinguish between the source files (yourdir/package/src), the
generated files (yourdir/package/LINUXLIBC6, yourdir/package/SOLgnu,
yourdir.package/NT386). When you are finished with testing the generated
libraries and programs you can install them ("****p"). Source code files go
to the central cm3/pkg, executables to cm3/bin (here on my Linux
installation), libraries to cm3/lib. Installed source code files are not
intended for further compilation as far as I know but for studies and
do***entation. In m3makefile you can control which files to ****p and this
way it is possible to intentionally install incomplete sources, e.g.
interfaces without implementations.
> 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.
> 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.
Recently I asked a similar question:
http://groups.google.de/groups?dq=&hl=de&lr=&ie=UTF-8&threadm=HItutF.1qs3%40luthien.in-berlin.de&prev=/groups%3Fdq%3D%26num%3D25%26hl%3Dde%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.modula3%26start%3D25
> I have noticed the m3override-files but according to the
> do***entation using overrides prevents ****pping.
m3override is for testing programs that shall im****t uninstalled
libraries. This should be a tem****ary state.
|
