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

[Mika Nystrom]

Jay K writes:
>
>The old target names are still available.
>
>
...
>
>*However* notice that cm3 is *not* preconfigured/predisposed for any partic=
>ular target.

cm3 -version prints a target...

>
>
>It has a list of targets and it can handle any of them. The config file dec=
>ides the target.
>=A0In fact=2C neither cm3 nor the config files are particularly knowledable=
> about targets.
>=A0 The config files vary a little in how they run the compiler or linker.
>=A0 cm3 varies mainly in word size=2C endianness=2C and jmpbuf size.
>=A0 All the real work of knowing about targets is buried in gcc.
>=A0 And a smattering of #ifdefs in C code. Some of which could be pushed to=
> autoconf.
>
>
>The old names confuse people -- you=2C for example.
>They are inconsistent.
>They don't specify processor architecture.
>

Well I agree with that much..

>
>What pain did you all go through when FreeBSD changed to FreeBSD2 changed t=
>o FreeBSD3 changed to FreeBSD4?
>Or LINUX to LINUXELF to LINUXLIBC6?
>So long ago nobody remembers?
>I used LINUXELF a little=2C built it=2C went away=2C came back and there wa=
>s LINUXLIBC6. I had no code. It didn't matter to me.
>

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.

     Mika