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

Mika Nystrom mika at async.async.caltech.edu
Mon Jul 19 16:47:22 CEST 2010


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



More information about the M3devel mailing list