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

[Jay K]

BUILD_DIR = "MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386"
TARGET = "FreeBSD4"

yes.

I can't say I've ever done it, but it is supposed to work, and there is the profile precedent Olaf mentioned.

Now, let's ask ourselves something important.
Where does it ship to?
Either it ships to BUILD_DIR, good, you get to rebuild everything (m3core, libm3, etc.) whenever you change BUILD_DIR.


Or it ships to TARGET and my story is completely wrong.
Unless we change it to BUILD_DOR.


Let me see.
We ship to build_dor.


And I'm proposing...devil will in the details, actually doing it, seeing if it works out..if the config file sets
word size (it already does, long ago), endian (I added recently), jmpbuf size... then TARGET might become
even less meaningful. I think the alignments are all the same. The types are all the same, given word size.
The floating point types are all the same, for now (I'm threatening to add VAX and 80bit x86 long double),
but still that could be config file... then the compiler (cm3) is left knowing nothing of any predefined targets..


Currently TARGET must be from within a list the compiler knows about.
BUILD_DIR is supposed to be arbitrary.
The "ship no resolution" stuff has some dependency that build_dir == target, but that's ok.


 - Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] moving to new target names, in Hudson?
> Date: Mon, 19 Jul 2010 07:47:22 -0700
> From: mika at async.async.caltech.edu
>
>
> Well Jay, from the user's point of view it really doesn't matter whether
> cm3 is one binary or many... BUILD_DIR has more to do with whether
> the binaries that it produces can run on one platform or many.
>
> But from what I gather from your email, the idea seems to be that you
> can have many targets in one compiler and the user of the compiler
> can set BUILD_DIR himself, as he pleases? That would be wonderful...
> Does it work to do that? Can I just change BUILD_DIR to, say,
>
> MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386
>
> and have everything work for me?
>
> Mika
>
> Jay K writes:
> >
> >Well=2C from the compiler (cm3=2C cm3cg) and libraries (m3core/*.m3=2C etc.=
> >) point of view=2C now=2C all I386_FREEBSD are the same.
> >=A0They are all little endian=2C 32bit word=2C have the same jmpbuf=2C and =
> >no stack walker.
> >=A0(Ok=2C there's a small difference in that older FreeBSD might not have d=
> >ecent enough pthreads.
> >=A0 So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_u=
> >serthreads.
> >=A0=A0=A0 But this still is overkill. They are still identical in cm3 and c=
> >m3cg. They vary only in m3core/*/m3makefile.
> >=A0=A0 I think this is best done by making the "thread library" a variable =
> >that the user can edit in config file.
> >=A0=A0 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.
> >=A0 I386_FREEBSD1=20
> >=A0 I386_FREEBSD2=20
> >=A0
> >I386_FREEBSD3=20
> >=A0
> >I386_FREEBSD4=20
> >=A0
> >I386_FREEBSD5=20
> >=A0
> >I386_FREEBSD6=20
> >=A0
> >I386_FREEBSD7=20
> >=A0 I386_FREEBSD8
> >=A0 I386_SOLARIS2.8 =A0=20
> >
> >
> >
> >=A0 I386_SOLARIS2.9=A0=20
> >
> >
> >=A0 I386_SOLARIS2.10=20
> >
> >
> >
> >=A0 I386_SOLARIS2.11=A0=20
> >
> >
> >
> >
> >Exposing this explosion in more than maybe one directory=2C I quite dislike=
> >.
> >They could be config files that set BUILD_DIR=2C maybe THREAD_LIBRARY (whic=
> >h I just made up) and then include(I386_FREEBSD).
> >I like to think they are "configurations"=2C lightweight toplevel things=2C=
> > many of them=2C that quickly devolve into a small number of "targets".
> >
> >
> >
> >Maybe what we should really=2C like=2C is run config.guess and use its enti=
> >re 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 eve=
> >r use that.
> >Perhaps not that anyone ever has TARGET !=3D BUILD_DIR.
> >=A0 Though that is how Modula-3 works for Cygwin.
> >
> >
> >I am slowly believing in the way of autoconf and the GNU build system. It m=
> >ust be observed.
> >On one hand that exposes a combinatorial explosion of configurations.
> >On the other=2C it avoids canonizing any particular combination as special.=
> >=20
> >
> >
> >If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing=2C a=
> >nd record that merely in the config file=2C
> >we'd be left with basically only four architectures in cm3: little endian32=
> >=2C little endian64=2C big endian32=2C big endian64.
> >
> >
> >Heck=2C 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 set=
> >jmp)=2C if there is a stack walker (usually false but sometimes true).
> >
> >
> >
> >=A0- Jay
> >
> >----------------------------------------
> >> To: jay.krell at cornell.edu
> >> Date: Mon=2C 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=2C in Hudson?
> >>
> >> Jay K writes:
> >> >
> >> >The old target names are still available.
> >> >
> >> >
> >> ...
> >> >
> >> >*However* notice that cm3 is *not* preconfigured/predisposed for any par=
> >tic=3D
> >> >ular target.
> >>
> >> cm3 -version prints a target...
> >>
> >> >
> >> >
> >> >It has a list of targets and it can handle any of them. The config file =
> >dec=3D
> >> >ides the target.
> >> >=3DA0In fact=3D2C neither cm3 nor the config files are particularly know=
> >ledable=3D
> >> > about targets.
> >> >=3DA0 The config files vary a little in how they run the compiler or lin=
> >ker.
> >> >=3DA0 cm3 varies mainly in word size=3D2C endianness=3D2C and jmpbuf siz=
> >e.
> >> >=3DA0 All the real work of knowing about targets is buried in gcc.
> >> >=3DA0 And a smattering of #ifdefs in C code. Some of which could be push=
> >ed to=3D
> >> > autoconf.
> >> >
> >> >
> >> >The old names confuse people -- you=3D2C 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 change=
> >d t=3D
> >> >o FreeBSD3 changed to FreeBSD4?
> >> >Or LINUX to LINUXELF to LINUXLIBC6?
> >> >So long ago nobody remembers?
> >> >I used LINUXELF a little=3D2C built it=3D2C went away=3D2C came back and=
> > there wa=3D
> >> >s LINUXLIBC6. I had no code. It didn't matter to me.
> >> >
> >>
> >> The point of these names=2C I thought=2C was that they were supposed to m=
> >ap
> >> to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3
> >> at the same time. We had a cluster with machines with both OSes=2C which
> >> were not binary compatible. The point is so that you can run cm3/m3build
> >> for both in the same repository (even concurrently)=2C 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
> > =