[M3devel] Release engineering

[Peter Eiserloh]

Hi Jay and Everyone,

> from: Jay jay.krell at cornell.edu
> date: Wed May 6 23:40:24 CEST 2009
>apt-get install cm3 would be nice, agreed.
>You have to be an official Debian developer though, right?

In order to submit a debian package for inclusion into the 
Debian distribution.  Even so, one can become a new maintainer
and study under a mentor.

Regardless of that, we can create our own packages and put
them in our own repository, until one of us does become involved
in the debian, ubuntu, linux-mint, ..., etc distributions.

I myself, have built a number of debian packages, these were 
intended for local operations, and never sent out of the work
area.  Actually, the *.deb files were burnt to CD, and installed
on a target machine.



>> o Allow cm3 to be installed into /usr, instead of /usr/local.
>
>Doesn't that already work?
>I don't do it, but it should work.

Okay, I will attempt to ship into a path like /usr/opt/cm3
just to exercise that ablility.  After testing to verify the
installation, I will delete it.  Then I will attempt to 
install into temporary directory, followed by copying into
a final destination /usr/opt/cm3, and test.

> Look at make-dist.py? And the others?
Okay, when I will before attempting the above.


>> o Documentation: Write manual page for cm3.
>Yep.

Okay I did this.  It can be downloaded from the link below.

   http://www.eiserloh.org/~peter/modula3/



>> o Allow easy cross compiling.
>
> We do already, sort of, and for some definition of "easy".
> In particular, cross /compilation/ of Modula-3 is easy.
> There is some C code and there is some linking.
> Cross building involves
>   cross compile the Modula-3, to assembly.
>   tar it up 
>   copy it over to target system
>   extract
>   make -- which compiles C and links
> 
> Doing a "full" cross build should just be a matter of
> either altering $PATH or the config file to find a different
> C compiler and linker.
> You also need a cm3cg per target.
> My config files (now the config files) do probe around
> in "reasonable" way (a little too haphazard really)
> so that you can have multiple cm3cgs, don't have to edit $PATH
> or copy files aorund.

> However, another idea is to declare that the configuration
> is not in fact user editable.

Now you are getting the IDEA.

Currently to do a cross compile the user has to change
a global (system) configuration file.  This would interfere
with any other user on the system, and of course require
super-user privileges.   The important part is that it 
would INTERFERE with the OTHER users.  (Sorry for shouting).


Okay, what I would like to see, is something like
# apt-get install cm3-compiler-ppc-darwin
# apt-get install cm3-compiler-amd64-darwin
# apt-get install cm3-compiler-amd64-freebsd
# apt-get install cm3-compiler-sparc64-solaris
# apt-get install cm3-compiler-nt386
# exit
$ ls /usr/cm3/bin
cm3
cm3cg-AMD64_DARWIN
cm3cg-AMD64_FREEBSD
cm3cg-AMD64_LINUX
cm3cg-NT386
cm3cg-PPC_DARWIN
cm3cg-SPARC64_SOLARIS


$ls /usr/cm3/etc
cm3.cfg
AMD64_DARWIN
AMD64_FREEBSD
AMD64_LINUX
NT386
PPC_DARWIN
SPARC64_SOLARIS


Now cm3.cfg contains one line
   Include("AMD64_LINUX");

Because this is the architecture of the host machine.

> That's how I do things already, long time now.

Yes, I like the idea of the main configuration simply
including the real one.  It is conceptually easier to 
understand.  When I saw that about a year ago, I really
liked it, thanks.

I just took that idea one step further.

The other TARGET files in ${CM3PATH}/etc, are designed
for cross compiling, they use the linker on the host
computer.

    cm3 --use-config=NT386

would invoke assembler: i586-mingw32msvc-as and 
linker: i586-mingw32msvc-ld.

Then any of the many users on the machine may attempt a 
cross compile without interfering with any other user.
By using either a command line argument, or the environment
variable M3CONFIG, the compiler will be informed which target
is requested.

NOTE: I think the cm3 frontend is currently target independent,
after parsing the source code, it calls a backend (eg, 
cm3cg-PPC_DARWIN) to generate the object code.

For example with M3CONFIG

  $ M3CONFIG=PPC_DARWIN cm3 -build

Alternatively using an argument (here I invent --use-config,
it looks cleaner).

  $ cm3 --use-config=PPC_DARWIN -build

Lastly, if I (a normal user) were experimenting with different
config files

   cm3 --use-config=/home/peter/src/experiment/mysuper.cfg -build


> Can you help?
Step one (the easy one) was to write a manual page for cm3.
Please comment, so that we can flush out any problems and 
add anything.  Maybe document the runtime @m3options.

Again
    http://www.eiserloh.org/~peter/modula3/


BTW: I got my example m3hexdump.m3 program to work, but
only if I don't specify the desired program name, so
the resulting executable is "../AMD64_LINUX/prog".


peter at black:~/modula-3/m3hexdump/src $ cm3 -o M3Hexdump
--- building in ../AMD64_LINUX ---

 -> linking M3Hexdump

Fatal Error: incomplete program

missing "Main" module




Peter

+--------------------------------------------------------+
| Peter P. Eiserloh                                      |
+--------------------------------------------------------+