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

[Jay K]

Well, from the compiler (cm3, cm3cg) and libraries (m3core/*.m3, etc.) point of view, now, all I386_FREEBSD are the same.
 They are all little endian, 32bit word, have the same jmpbuf, and no stack walker.
 (Ok, there's a small difference in that older FreeBSD might not have decent enough pthreads.
  So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_userthreads.
    But this still is overkill. They are still identical in cm3 and cm3cg. They vary only in m3core/*/m3makefile.
   I think this is best done by making the "thread library" a variable that the user can edit in config file.
   And maybe gets appended to BUILD_DIR. But TARGET is unchanged.)


Any differences or binary compatibilities aren't present until m3core/*.c #includes varying headers.
I think it makes more sense probably for people to start editing BUILD_DIR in their config files.
  I386_FREEBSD1 
  I386_FREEBSD2 
 
I386_FREEBSD3 
 
I386_FREEBSD4 
 
I386_FREEBSD5 
 
I386_FREEBSD6 
 
I386_FREEBSD7 
  I386_FREEBSD8
  I386_SOLARIS2.8   



  I386_SOLARIS2.9  


  I386_SOLARIS2.10 



  I386_SOLARIS2.11  




Exposing this explosion in more than maybe one directory, I quite dislike.
They could be config files that set BUILD_DIR, maybe THREAD_LIBRARY (which I just made up) and then include(I386_FREEBSD).
I like to think they are "configurations", lightweight toplevel things, many of them, that quickly devolve into a small number of "targets".



Maybe what we should really, like, is run config.guess and use its entire output: i386-unknown-freebsd4.11
Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow computed from that?




BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I ever use that.
Perhaps not that anyone ever has TARGET != BUILD_DIR.
  Though that is how Modula-3 works for Cygwin.


I am slowly believing in the way of autoconf and the GNU build system. It must be observed.
On one hand that exposes a combinatorial explosion of configurations.
On the other, it avoids canonizing any particular combination as special. 


If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing, and record that merely in the config file,
we'd be left with basically only four architectures in cm3: little endian32, little endian64, big endian32, big endian64.


Heck, it doesn't even need to be autoconfish. It just needs to be in the config files.
And a very small number of other things: the name of setjmp (_setjmp or setjmp), if there is a stack walker (usually false but sometimes true).



 - Jay

----------------------------------------
> To: jay.krell at cornell.edu
> Date: Mon, 19 Jul 2010 04:02:07 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] moving to new target names, in Hudson?
>
> 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