[M3devel] moving to new target names, in Hudson?

[Olaf Wagner]

Quoting Mika Nystrom <mika at async.async.caltech.edu>:
[...]
> The point of these names, I thought, was that they were supposed to map
> to binary-incompatible systems.  I remember having FreeBSD2 and FreeBSD3
> at the same time.  We had a cluster with machines with both OSes, which
> were not binary compatible.  The point is so that you can run cm3/m3build
> for both in the same repository (even concurrently), and not have them
> interfere with each other.  It's not a pain to have different names
> if they actually mean different things.  If you just call everything
> I386_FREEBSD all hell will break loose in that situation... (just as when
> I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where
> I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...)
>
> Or am I misunderstanding something here?  I would have thought you really
> wanted to have a different name for each binary-incompatible system so
> you can build them all in the same place.  Consistency in naming would be
> nice but I think it is secondary.

In theory, yes, but it hasn't always worked out in practice.
Binary compatibility works at least in two directions:

  (a) Allow applications compiled on an older system with older tools
      and libraries to be run on a newer system.

  (b) Allow applications compiled on a newer system to run on all or
      certain selected older system versions.

Usually (a) is provided by Open Source systems like Linux, FreeBSD etc.,
at least within a major release line, sometimes also crossing boundaries
(remember the switch from aout to elf format in FreeBSD).

(b) is often partially provided by commercial systems like Windows, though
in practice this doesn't always work as expected, too.

It would be nice if we really could follow all binary compatibility
changes in all supported operating system targets with a new unique
name, but I'm afraid we haven't been able to do that in the past nor
will we succeed to do that in the future.

You have experienced one failure as you tried the FreeBSD4 packages
built on FreeBSD 6.4 on an actual FreeBSD 4.11 system.

We may get better if we distinguish between different uses of the target
platform name though:

  (1) TARGET as a choice for compilation variants that cm3 distinguishes
      internally

  (2) TARGET as a name for the directories containing derived files (which is
      already configurable in quake config files). For example, the profiling
      setups I made some years ago added a `p' to the TARGET name.

  (3) TARGET as an indicator for installation or other binary packages
      on which system these binaries may run

(3) should include as many information as possible, though it is not
clear to me where to stop here. Do we actually want the X version or
the GUI support libraries to be included there? What if different loadable
formats are supported, as under Darwin (PPC, I386, combined) or Windows
(com, exe (coff))? I would tend to start with something like the
output of uname -rsm here:

   o FreeBSD 8.0-STABLE amd64
   o Linux 2.6.26-2-amd64 x86_64
   o FreeBSD 6.4-RELEASE-p5 i386
   o Darwin 9.8.0 i386
   o Darwin 8.11.0 Power Macintosh

We could also add a more or less unspecified variant part there, for
example, if we need to distinguish between aout/coff/elf format.

(1) should be the list of distinctions we need to make to support
different target platforms. The current compromise seems to be that
this is a combination of processor/machine architecture (like I386, AMD64)
and operating system name (not version).

Then (2) could be an installation-specific choice: either just use
the more generic name from (1), or a combination of (1) and (3), or
some arbitrary name. It's not completely thought through yet, so suggestions
on what exactly would be required or great are welcome.

I've already added the information of (3) to the CM3 5.8.6 download
pages; the next release should include it in the actual package names.

(1) should be consistently standardized if possible (i.e. FreeBSD1/2/3/4
  --> I386_FREEBSD etc.). Many actual configuration options may be
determined by auto-configuration then.

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