[M3devel] platform/build_dir is a big tuple?

[Mika Nystrom]

This sounds wonderful!!

    Mika

P.S. Personally I don't care about pthreads, user threads, or any
other kind of threads.  I think Modula-3 threads are beautiful (one
of the real strengths of the language, in fact), and good as never
see a need to delve any lower than that.  Win32 threads work fine
on the old NT386GNU.  There were no pthreads back then, and probably
Win32 threads are better than user threads anyhow... (in the sense
of requiring fewest "anti-blocking" hacks).  Of course there might
be someone out there who doesn't agree, and needs Modula-3 threads
to be built on pthreads for some reason...

Jay writes:
>--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Let me cut to the chase, again:
>=20
> Everyone will probably be satisfied.=20
> For a very small "everyone". :)=20
>=20
>The underlying implementation shall be "heavily" parameterized.
>There shall be three visible pre packaged configurations.
>Power users, and clever and crazy people can experiment beyond those three.
>The EXACT three configurations is SLIGHTLY up in the air, but is likely to =
>be:
>=20
>NT386
>  same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 ker=
>nel threads, native backslashy paths (and perhaps increased compat with for=
>ward slashes, some of that is already in, m3core, but not yet cm3), Visual =
>C++ compiler and linker.
>=20
>NT386MINGNU
>  same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working=
>=20
>   external backend, gcc compiler and linker, but otherwise same as NT386
>  One small wrinkle here is there is no m3gdb, but you can use the m3gdb fr=
>om the next one, or Cygwin's gdb.
>=20
>NT386GNU
>  As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C l=
>ibrary, stupid looking paths that start /cygdrive, wierdo symlinks that don=
>'t interoperate well with the rest of the system (attempting to run cc.exe =
>crashes ntvdm.exe, for example), "link" makes file system links (or at leas=
>t strange files) instead of linking programs, a slow and perhaps fragile co=
>py-immediately implementation of fork, problems running one type of program=
> from another because you don't know which command line parameters and whic=
>h environment variables represent paths or lists of paths and therefore how=
> to translate them, etc.=20
>The underlying parameters, which are largely independent and which you can =
>change individually, but which you will actually just ignore usually, shall=
> be:
>=20
>  modula-3 backend
>     integrated 0
>     cm3cg 1
>   This might be replaced by the existing 0-3 variable.
>=20
>  C compiler =20
>    Visual C++ cl 0
>    gcc 1
>    In future this could be redefined as decimal digit or a character to ac=
>comodate other choices.
>=20
>  linker
>     Visual C++ link 0
>     gcc 1
>    In future this could be redefined as decimal digit or a character to ac=
>comodate other choices.
>=20
>   Threading library
>     Native Win32 kernel threads 0
>     Cygwin pthreads which are probably layered on native Win32 kernel thre=
>ads 1
>     This is the one area where people have suggested using native Win32 fu=
>nctionality instead of Cygwin
>     vtalaram user threads probably not available
>     fiber user threads probably not available
>          This would have been better than vtalaram, but not Win9x compatib=
>le
>     If anyone wanted user vtlaram or fiber, this could be extended. It pro=
>bably always should have been fibers instead of setjmp/longjmp where fibers=
> are available...
>=20
>   Window library
>      Native Win32 gui 0 (hopefully with bugs to be worked out)=20
>      X Windows via CygwinX 1 (hopefully the binaries are X server agnostic=
>, and even work against a remote Unix machine?)
>=20
>    C library
>      native msvcr* through Visual C++ or MinGWin 0
>      Cygwin and its path oddities 1=20
>=20
>The current notion of "OSTYPE" becomes much less useful here, as it previou=
>sly embodied multiple factors.
> It wasn't all that useful anyway, imho, but as a way to reduce the matrix =
>of targets down to two, the same two in multiple places. Now, in a few plac=
>es, you check a more specific variable. Theoretically, I don't have to chan=
>ge cm3 here, just the config file and some m3makefiles. Because, tricky tri=
>cky, the main thing cm3 cares about is the backend "mode", and that does ma=
>tch up above with the 0/1. There are actually 4 modes and I should maybe ho=
>ist that up to be the variable, very maybe. A few m3makefiles will have to =
>change, in small ways.
>=20
>  Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe thread=
>ing, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the r=
>est 0. Besides that, what I haven't in my head yet, is that individual m3ma=
>kefiles should be able to ask for one compiler or the other. The base syste=
>m won't do that, but user systems could, if they have some code that depend=
>s on one compiler or the other and they are going to link it together. For =
>this purpose, for exposing these features to users, possibly values other t=
>han "0" and "1" are needed.
>=20
>If the configuration is one of these three combinations, build_dir is trans=
>lated as shown.
>Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s.
>=20
>This is essentially already commited. NT386 works this way. NT386MINGNU wor=
>ks this, but is for now called NT386GNU, and doesn't have any Trestle yet. =
>The new/old Cygwin NT386GNU isn't active yet, but easily should be.
>=20
>There are three config files, NT386, NT386MINGNU, NT386GNU, they are all ju=
>st a few lines and then include NT386.common.
>=20
>Oh, one more thing I haven't worked out is how the user asks for one target=
> or another.
>It is probably via the environment variable CM3_TARGET, though in reality, =
>"TARGET" for all of these shall be NT386.
>=20
>Any questions?
>Don't ask me when Cygwin NT386GNU will be active or when the names will fli=
>p. I will try it soon.
>=20
>This is essentiallyalready in the tree, with a little bit of "temporary, fo=
>r compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the =
>Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, =
>I think I've stopped thinking through the indecisiveness, I just keep heari=
>ng the two extreme sides, the Windows users who want Windows (do you even c=
>are about the gcc backend? It's slow. It generates inefficient code. It sup=
>ports Longint) and a few Unix users who might reluctantly use Windows a lit=
>tle more if their backend slowed down and their libraries changed...
>=20
>Personally my main goal here is to not feel guilty about not finishing the =
>LONGINT support yet in the integrated backend.
>I'd still like to finish that, but it was taking embarassingly long.
>=20
>I'd also like an uber-cross build environment, where I can build anything f=
>rom anything. Getting cm3cg working was part of that. I'm not sure I have t=
>he patience to build gcc and ld/binutils that many times though.
>=20
>   - Jay
>
>
>
>> Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.d=
>e> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn=
>@scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22=
> Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I =
>am happy to stay with the underlying OS, the> > native windows threading, t=
>he integrated backend, and use the free> > Microsoft Visual Studio tools. I=
> don't really want to have to> > install/use cygwin or any of the other var=
>iants. When I see target =3D> > NT386, this list is what I am expecting. Fo=
>r the cm3 newbie coming from> > a Microsoft Windows environment, I think th=
>is list would be the most> > appealing and pose the least barrier to gettin=
>g starting. Yes, I still> > will work on the installer program once I'm sat=
>isfied that I have a good> > working cm3 on Windows.> > One year ago I was =
>in the situation to port one of my Modula-3 programs> from Linux to Windows=
> in order to hand it over to a Windows user. As I> never use Windows, I hav=
>e only a plain Windows installation on my machine> with almost no tools oth=
>er than cm3. I was glad to be able to run cm3> immediately and to find all =
>libraries that I needed in binary form without> Cygwin dependencies - other=
>wise not only I had to install that on my> machine but I also would have to=
> persuade the other Windows guy to install> it as well. Summarized I strong=
>ly vote for NT386 being Windows with least> dependencies on other packages.
>_________________________________________________________________
>Connect and share in new ways with Windows Live.
>http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120=
>08=
>
>--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px;
>padding:0px
>}
>body.hmmessage
>{
>FONT-SIZE: 10pt;
>FONT-FAMILY:Tahoma
>}
></style>
></head>
><body class=3D'hmmessage'>Let me cut to the chase, again:<BR>
> <BR>
> Everyone will probably be satisfied. <BR>
> For a very small "everyone". :) <BR>
> <BR>
>The underlying implementation shall be "heavily" parameterized.<BR>
>There shall be three visible pre packaged configurations.<BR>
>Power users, and clever and crazy people can experiment beyond those three.=
><BR>
>The EXACT three configurations is SLIGHTLY up in the air, but is likely to =
>be:<BR>
> <BR>
>NT386<BR>
>  same as today, integrated backend, Win32 GUI, msvc*.dll, native win3=
>2 kernel threads, native backslashy paths (and perhaps increased compat wit=
>h forward slashes, some of that is already in, m3core, but not yet cm3), Vi=
>sual C++ compiler and linker.<BR>
> <BR>
>NT386MINGNU<BR>
>  same as today's (recent) NT386GNU, but with Trestle-on-Win32 al=
>so working <BR>
>   external backend, gcc compiler and linker, but otherwise same =
>as NT386<BR>
>  One small wrinkle here is there is no m3gdb, but you can use the m3g=
>db from the next one, or Cygwin's gdb.<BR>
> <BR>
>NT386GNU<BR>
>  As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwi=
>n C library, stupid looking paths that start /cygdrive, wierdo symlinks tha=
>t don't interoperate well with the rest of the system (attempting to run cc=
>.exe crashes ntvdm.exe, for example), "link" makes file system links (or at=
> least strange files) instead of linking programs, a slow and perhaps =
>fragile copy-immediately implementation of fork, problems running one type =
>of program from another because you don't know which command line parameter=
>s and which environment variables represent paths or lists of paths and the=
>refore how to translate them, etc. <BR><BR>
>The underlying parameters, which are largely independent and which you can =
>change individually, but which you will actually just ignore usually, =
>shall be:<BR>
> <BR>
>  modula-3 backend<BR>
>     integrated 0<BR>
>     cm3cg 1<BR>
>   This might be replaced by the existing 0-3 variable.<BR>
> <BR>
>  C compiler  <BR>
>    Visual C++ cl 0<BR>
>    gcc 1<BR>
>    In future this could be redefined as decimal digit or a =
>character to accomodate other choices.<BR>
> <BR>
>  linker<BR>
>     Visual C++ link 0<BR>
>     gcc 1<BR>
>    In future this could be redefined as decimal digit or a =
>character to accomodate other choices.<BR>
> <BR>
>   Threading library<BR>
>     Native Win32 kernel threads 0<BR>
>     Cygwin pthreads which are probably layered on nati=
>ve Win32 kernel threads 1<BR>
>     This is the one area where people have suggested u=
>sing native Win32 functionality instead of Cygwin<BR>
>     vtalaram user threads probably not available<BR>
>     fiber user threads probably not available<BR>
>          This would have been=
> better than vtalaram, but not Win9x compatible<BR>
>     If anyone wanted user vtlaram or fiber, this could=
> be extended. It probably always should have been fibers instead of setjmp/=
>longjmp where fibers are available...<BR>
> <BR>
>   Window library<BR>
>      Native Win32 gui 0 (hopefully with bugs to b=
>e worked out) <BR>
>      X Windows via CygwinX 1 (hopefully the binar=
>ies are X server agnostic, and even work against a remote Unix machine?)<BR=
>>
> <BR>
>    C library<BR>
>      native msvcr* through Visual C++ or MinGWin =
>0<BR>
>      Cygwin and its path oddities 1 <BR>
> <BR>
>The current notion of "OSTYPE" becomes much less useful here, as it previou=
>sly embodied multiple factors.<BR>
> It wasn't all that useful anyway, imho, but as a way to reduce the ma=
>trix of targets down to two, the same two in multiple places. Now, in a few=
> places, you check a more specific variable. Theoretically, I don't have to=
> change cm3 here, just the config file and some m3makefiles. Because, trick=
>y tricky, the main thing cm3 cares about is the backend "mode", and that do=
>es match up above with the 0/1. There are actually 4 modes and I should may=
>be hoist that up to be the variable, very maybe. A few m3makefiles will hav=
>e to change, in small ways.<BR>
> <BR>
>  Therefore, NT386 is all 0s, NT386GNU shall be all 1s, exce=
>pt maybe threading, and NT386MINGNU shall be a mix -- backend, C =
>compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet=
>, is that individual m3makefiles should be able to ask for one compiler or =
>the other. The base system won't do that, but user systems could, if they h=
>ave some code that depends on one compiler or the other and they are going =
>to link it together. For this purpose, for exposing these features to users=
>, possibly values other than "0" and "1" are needed.<BR>
> <BR>
>If the configuration is one of these three combinations, build_dir is trans=
>lated as shown.<BR>
>Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s.<BR>
> <BR>
>This is essentially already commited. NT386 works this way. NT386MINGNU wor=
>ks this, but is for now called NT386GNU, and doesn't have any Trestle yet. =
>The new/old Cygwin NT386GNU isn't active yet, but easily should be.<BR>
> <BR>
>There are three config files, NT386, NT386MINGNU, NT386GNU, they are all ju=
>st a few lines and then include NT386.common.<BR>
> <BR>
>Oh, one more thing I haven't worked out is how the user asks for one target=
> or another.<BR>
>It is probably via the environment variable CM3_TARGET, though in reality, =
>"TARGET" for all of these shall be NT386.<BR>
> <BR>
>Any questions?<BR>
>Don't ask me when Cygwin NT386GNU will be active or when the names will fli=
>p. I will try it soon.<BR>
> <BR>
>This <EM>is essentiallyalready in the tree</EM>, with a little bit of "temp=
>orary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet,=
> and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork =
>is laid, I think I've stopped thinking through the indecisiveness, I just k=
>eep hearing the two extreme sides, the Windows users who want Windows (do y=
>ou even care about the gcc backend? It's slow. It generates inefficient cod=
>e. It supports Longint) and a few Unix users who might reluctantly use Wind=
>ows a little more if their backend slowed down and their libraries changed.=
>..<BR>
> <BR>
>Personally my main goal here is to not feel guilty about not finishing the =
>LONGINT support yet in the integrated backend.<BR>
>I'd still like to finish that, but it was taking embarassingly long.<BR>
> <BR>
>I'd also like an uber-cross build environment, where I can build anything f=
>rom anything. Getting cm3cg working was part of that. I'm not sure I have t=
>he patience to build gcc and ld/binutils that many times though.<BR>
> <BR>
>   - Jay<BR><BR><BR>
>
><HR id=3DstopSpelling>
><BR>
>> Date: Wed, 23 Jan 2008 08:06:20 +0100<BR>> From: lemming at henning-th=
>ielemann.de<BR>> Subject: Re: [M3devel] platform/build_dir is a big tupl=
>e?<BR>> To: rcoleburn at scires.com<BR>> CC: m3devel at elegosoft.com; jayk=
>123 at hotmail.com<BR>> <BR>> <BR>> On Tue, 22 Jan 2008, Randy Colebu=
>rn wrote:<BR>> <BR>> > Jay:<BR>> ><BR>> > For my part =
>on Windows, I am happy to stay with the underlying OS, the<BR>> > nat=
>ive windows threading, the integrated backend, and use the free<BR>> &gt=
>; Microsoft Visual Studio tools. I don't really want to have to<BR>> &gt=
>; install/use cygwin or any of the other variants. When I see target =3D<BR=
>>> > NT386, this list is what I am expecting. For the cm3 newbie comi=
>ng from<BR>> > a Microsoft Windows environment, I think this list wou=
>ld be the most<BR>> > appealing and pose the least barrier to getting=
> starting. Yes, I still<BR>> > will work on the installer program onc=
>e I'm satisfied that I have a good<BR>> > working cm3 on Windows.<BR>=
>> <BR>> One year ago I was in the situation to port one of my Modula-=
>3 programs<BR>> from Linux to Windows in order to hand it over to a Wind=
>ows user. As I<BR>> never use Windows, I have only a plain Windows insta=
llation on my machine<BR>> with almost no tools other than cm3. I was gl=
>ad to be able to run cm3<BR>> immediately and to find all libraries that=
> I needed in binary form without<BR>> Cygwin dependencies - otherwise no=
>t only I had to install that on my<BR>> machine but I also would have to=
> persuade the other Windows guy to install<BR>> it as well. Summarized I=
> strongly vote for NT386 being Windows with least<BR>> dependencies on o=
>ther packages.<BR><BR><br /><hr />Connect and share in new ways with Window=
>s Live. <a href=3D'http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_W=
>ave2_sharelife_012008' target=3D'_new'>Get it now!</a></body>
></html>=
>
>--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_--