[M3devel] [Modula-3] Release engineering

[Jay]

----------------------------------------
> Date: Wed, 6 May 2009 10:04:12 -0700
> From: eiserlohpp
>
> Hi Olaf,
>
> Please help support distribution packaging (various Linux, or BSD ports)
> by adding to your list:

apt-get install cm3 would be nice, agreed.
You have to be an official Debian developer though, right?
 
As would cd /usr/ports/lang/cm3; make; make install.
There is ezm3 but..

> o Design the cm3 installation to be long term.

Specifically?

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

> o Allow installation to temporary root during package building.

This does work in a fashion, but maybe not sufficiently or easily enough.
But maybe both too. :)
Specifically, you can install the entire system to a temporary root.
You "have to" put the compiler, m3core, libm3 there, then you
can also put your own stuff there. My automation does this and
I think Olaf's does too.
Actually I think you can start out with just the compiler.
Look at make-dist.py? And the others?

> o Specify guidelines for which m3.pkgs go into which distribution
> packages (rpm, deb). List the suggested package names.

There is a delineation of "std" and "min".
The sh code is nicely data driven.
The Python actually is not currently.
More package sets could be defined, but it gets confusing.
Is it good that X was broken down into a bajillion packages or not?
Not clear to me.
 

> o Documentation: Write manual page for cm3.

 
Yep.

> o Conform where possible to the FHS.

Don't we? Is carving out /usr/local/cm3 against that?
Isn't conforming to FHS a matter of what we use, not where we install,
as long as we don't litter all over the system?
 

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

> o (lower priority) Use long form options.

 
We have so few options and personally I think -long is fine.
The only advantage of -a -b -c vs. -long is you can combine
-abc unambiguously. Heck even configure supports -long even
though the usage doesn't say so.
 
>
> (2) The build process of a package usually installs all files into a
> subdirectory where the internal paths mimic the final installation paths
> (/home/peter/src/modula3/cm3/src-all-20090506/debian/cm3-compiler).
> Libraries and executable's link paths should be adjusted to their
> final installation paths, not the temporary.

 
This is already fixed or in progress.
I've been mucking with "runpath" lately.
 
I'd like to do more here, soon.
 
There isn't one answer though.
We have "buildlocal" and "buildglobal".
And people want to be able to run "unshipped" (not installed) binaries.
Currently the compromise:
 buildlocal has those paths 
 buildglobal does not 
 if you want to run uninstalled buildglobal, use build_standalone
 relinking upon install has been discussed but so far isn't done. 
  I know some systems do that (via libtool).
 

> (3) May I suggest this start: cm3-compiler, cm3-corelibs (minimal
> install: m3core, libm3 binaries), cm3-devel (source code to m3core,
> and libm3), ..., etc.
>
> What I don't want to see is the mass installation of a complete
> development system simply because the user wanted to use a program
> written in Modula-3.

Understood. There are a lot shared libs though.
The "min" package set satisfies many programs, but not all.
build_standalone is available but not great.

> Something like:
> mypath := FindAbsolutePath(argv[0]);
> cm3_bin_path := DirName(mypath);
> cm3_path := DirName(cm3_bin_path);
> cm3_etc_path := cm3_path & "/etc";
> cm3_config_filename = cm3_etc_path & "/cm3.cfg";

 
Ah. Not sure. /etc vs. next to the binary.
I do probe around for next to the binary + target platform,
for the configuration and the backend.
 
Probing for ../etc I guess is reasonable.
That way you can rm -rf the "installation" without
losing the configuration.
 
However, another idea is to declare that the configuration
is not in fact user editable. I have tried to write
configuration files that work for everyone. But maybe
that is impossible. The actual parts that cminstall asks
about to make edits aren't really user settings. They are
OS settings that a better system would just get correct.
Like with autoconf -- do you expect to edit its output?
Only if desperate.
But it is gray.
Using "gcc" from $PATH vs. a full path to gcc?
Using gcc-3 or gcc-4 (Cygwin and MacOSX have such).
Are those "machine" settings decided during install?
Or user settings?
Go with the binary or in etc?
I'm not sure.
 

> (6) Cross compiling: the cm3.cfg should be a one liner, which includes
> the configuration of the installed target machine .
> cm3.cfg:
> Include("AMD64_LINUX");

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

> When cross compiling the user should be able to specify the actual config file for the desired TARGET machine.
 
 
My Python scripts accept a target machine on the command line.
cd scripts/python
 ./do-cm3-core.py buildship FreeBSD4 
 
 usually with boot: 
 
 ./do-cm3-core.py buildship FreeBSD4 boot  
 
but also when it is somewhat ambiguous like NT386 or NT386GNU.
This guides chosing a config file.
Granted, this should be in cm3, not layered on.
I've been "afraid" to take such big steps without working through
getting a large consensus. Layering on with Python, I can do
whatever the heck I want when I want. :)
 
 
Can you help?
 
 
 - Jay