[M3devel] [Modula-3] Release engineering

[Olaf Wagner]

That's quite a long wish list you've got there, and as it is not
Christmas, I'm afraid that we won't be able to fulfill all of them :-)

The release engineering I volunteered to undertake was not supposed
to add significant functionality to the existing code base; I'll
only try to package what is there, perform some tests, and urge
others to correct the bugs and shortcomings I find.

So if something isn't there and nobody volunteers to write it, it will
probably not make its way into the distribution. Indeed it would be
rather late for the now planned release to add new features.

Jay already made some comments, I'll add some more below, too.

Quoting Peter Eiserloh <eiserlohpp at yahoo.com>:

>
> Hi Olaf,
>
> Please help support distribution packaging (various Linux, or BSD ports)
> by adding to your list:
>
>   o Design the cm3 installation to be long term.

Hm. This is rather vague...

>   o Allow cm3 to be installed into /usr, instead of /usr/local.

That should already be possible; AFAIK there is no need to install
to a certain location.

>   o Allow installation to temporary root during package building.

Jay commented on it, but I'm not sure if that was what you meant.

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

Sure we can suggest a classification of M3 packages for installation
packages; I cannot build system dependent package formats though (unless
we automate that at a central and publicly reachable location).

>   o Documentation: Write manual page for cm3.

I can do that.

>   o Conform where possible to the FHS.

Don't we? You don't mean we should split up all the packages into
different locations, do you?

>   o Allow easy cross compiling.

Cross-compilation is never easy in my experience, but Jay has done
a lot of work in this area.

>   o (lower priority) Use long form options.

Where exactly? Perhaps we can add some additional long options
where you would most need them?

> Explaination:
>
> (0) Only the administrator should install packages into the system.
> If a user wants to play with a recent version of CM3, they should be
> able to install into their home directory.  This will allow the
> other users of the machine to continue using the known good compiler
> even though one user is experimenting with buggy new features of
> the compiler.  This will also allow easier cross compiling.
>
> (1) /usr/local is only for files/packages manually installed
> by the superuser.  Distributions are expected (in debian, required) to
> install into "/usr" (or if required to boot, into "/", eg., /sbin/mount).

That's exactly because the default installation of CM3 is /usr/local ;-)
We've never provided system-specific package formats until now.
Of course system packages should install into their preferred locations.

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

I doubt that I will be able to do something about the paths problems.
I hope that Jay's $ORIGIN uses will somehow be adequate.

> (3) May I suggest this start: cm3-compiler, cm3-corelibs (minimal
> install: m3core, libm3 binaries), cm3-devel (source code to m3core,
> and libm3), ..., etc.

CM3 always installs the complete source code along with the package
targets (libraries or programs), as there are many tools that rely
on it.

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

We always offered a minimal binary package. I'll think about a
useful classification of packages.

> (4) Debian at least requires a manual page for executables.  A bug
> will be written against any package that installs user (or superuser)
> binaries without a manual page.

I won't be able to provide manual pages for all M3 programs.

> (5) The Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/
> says things such as libraries are not execuables invocable by the user
> so don't put them in $(prefix)/bin.  Okay, MS-Windows violates this all
> the time, but they are "special".  Can we move cm3.cfg out of the binary
> directory (where there should only be executables), and into
> ${CM3_PATH}/etc.

I won't change anything concerning the configuration files at the
last minute. This will most likely result in weeks of delay (as it will
break lots of scripts and regression tests).

The location of configuration files can always be overridden by the
environment; system-specific packages should use this feature if necessary.
As I've said, several provided scripts will break, but they aren't
usually end-user relevant.

> 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";

I'm not against such changes, but they won't make it into this release,
and somebody will have to volunteer to do them.

> (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");
>
> When cross compiling the user should be able to specify the actual   
> config file for the desired TARGET machine.

Nice wish, but maybe Jay will deliver something here.

> (7) Although each program is free to define is command line arguments
> and options, a set of conventions has been in place for at least
> 15 years or more.  GCC of course (being an older program) violates
> these "recent" conventions.
>
> Options start with a dash.  Single letter options start with a
> single dash, and multiple options may be collected into one
> sequence (ie, "-shared", means -s, -h, -a, -r, -e, -d).  Long
> options use two dashes and signify that the sequence of characters
> are to be used as a complete string (ie, "--shared" means generate
> a "shared" library).  Long options that take an argument are formed
> with an equal sign (eg. "--config=/home/peter/cm3/etc/cm3.cfg").
>
> Instead of "-version" with a single dash, long form options use
> two dashes "--version", a single dash "-v" could also be mapped
> to be an alias of that option.

We can add some long options, as said before, but I'm not going
to break all backward compatibility by removing or changing existing
ones.

Someone will have to write an extended ParseParams module though :-)
Could you provide one?

> Sorry for being long winded, but my system administrator is a
> real hard ass, every time I see myself in the mirror, he reminds
> me of that.

Well, I hope he won't be too dissatisfied,

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194