[M3devel] platform/build_dir is a big tuple?

[Randy Coleburn]

Jay:
 
For my part on Windows, I am happy to stay with the underlying OS, the
native windows threading, the 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 variants.  When I see target =
NT386, this list is what I am expecting.  For the cm3 newbie coming from
a Microsoft Windows environment, I think this list would be the most
appealing and pose the least barrier to getting starting.  Yes, I still
will work on the installer program once I'm satisfied that I have a good
working cm3 on Windows.
 
Of course, I am just one voice.  If you can and want to provide for all
of the other variants on windows, that is ok with me.  Just don't do
away with what I have now.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 1/22/2008 8:00 AM >>>
I'm still torn over that any NT386 target could
  have a choice of three threading models (win32, pthread, vtalarm),
two
  windowing libraries (ms, x), two (three) compilers (ms, mingwin,
cygwin), two (three) linkers (ms, mingwn, cygwin), various runtimes
(msvc various versions, cygwin, mingwin (discouraged)) etc.
 
Appending a short string of unreadable bits to BUILD_DIR is very
tempting
in order to easily generate and test the combinatorial possibilities.
 
backend: 0 integrated, 1 gcc
 already a setting (with four values) 
 
ccompiler/linker: 0 ms, 1 gcc
 (these could be split, and could allocate more bits...)
 maybe 00 ms, 01 cygwin, 10 ming 
 maybe define enum up front that allows for watcom, metrowerks,
digitalmars, llvm etc.
 maybe use a decimal digit for all these, and 0 is reserved, maybe.
 
threading: 0 win32, 1 pthreads
  drop vtalarm, or use two bits?
 
windowing: 0 ms, 1 x
 
cruntime: 0 ms, 1 cyg
  There is also a ming runtime, discouraged
  There also really N ms runtimes, ming offers several:
   msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll...
   but jmpbuf presumbly doesn't change
 again could allocate multiple bits..
 
cruntime I guess determines oSTYPE Win32 or Posix, though
it loses its meaning mostly, and X vs. not-X is usually decide the
same...
 
The three most common combinations:
  00000 -- NT386
  11111 -- NT386GNU
  11000 -- NT386MINGNU
 
but several others would work
  11101 -- cygwin with native windowing
  11011 -- cygwin with native threads
  11001 -- cygwin with native threads and native windowing

 
BUILD_DIR would be NT386-$(config)
as a special case perhaps, the three common
cases could be translated to the above strings.
 
But the underlying implementation would be a few bools/enums,
and iterating through them would be easy, while special casing
and skipping deemed invalid combinations, like ms runtime and
pthreads,
and possibly ms runtime and x windows.
Really, it might surprise folks, but really, basically every single
combination works.
Compilers are very independent of headers and libs and headers and libs
are very independent of compilers, aside from a few language extensions
like __stdcall. You can generally mix runtimes in the same process, just
as you can mix them on the same machine, you just need to be careful
about what you pass to what. If you call fopen, be sure pass the result
back to the matching fclose, malloc/free, etc. Startup code, to the
extent that it matters, might be a problem, but really, just avoid C++
globals with constructors/destructors anyway, they are always a problem.
Modula-3 has its own startup code, and if you were to write "main" in C
and link in Modula-3 static .libs, that probably doesn't work...might
actually be better to play into whatever the platform's C++
constructor story is, as problematic as they (probably always?) are --
i.e. unpredictable/hard-to-control ordering.
 
(bad editing...and maybe use hex for compression..)
 
Bringing back cminstall is almost interesting, to prompt
the user, or probe their system, though Quake/cm3 can probe at
runtime.
if os == windows_nt
   system_cc | findstr version | findstr gcc
   else system_cc | findstr visual c++
else
   system_cc | grep version | grep gcc
   else system_cc | grep visual c++
end
 
inefficient.
 
anyway, I'll merge current NT386GNU into NT386 and make it chose
how to compile/link which are the main variables today.
and then decide about cygwin, but probably do like the above, since
it'll totally share code with NT386 except the naming conventions
and the removal of the -mno-cygwin switch..
 
I know this seems overly complicated, but it should be exposable
easily enough to users by hiding the choices, presenting three basic
ones,
and still allow all the obvious and perhaps useful knobs, and iterating
through
the combinations, without creating a combinatorial explosion of source
files
or Modula-3 or Quake code.

  ...Jay
From: jayk123 at hotmail.com 
To: m3devel at elegosoft.com 
Date: Tue, 22 Jan 2008 10:48:56 +0000
Subject: Re: [M3devel] platform/build_dir is a big tuple?

Final answer?
 
I played around with this but just can't accept platforms/build_dirs
like:
  ntx86msmsmscm3msn
  ntx86gccgcccm3cgmsn
  ntx86gccgcccm3cgxn
  ntx86-gggggmn
  ntx86-ggixn
  ntx86_mmmimm

Ok, I have one more name here, and then a bit of a change, or
 a stronger statement of something I had already said.

NT386MINGNU

Ok, I think we (me!) are confusing host and target, MOSTLY.

And cm3 might not have them quite divided appropriately.

What is a "host"? What is a "target"?

MinGWin and Visual C++ output similar results, targeting
the same runtime (usually), threading library, windowing library.
There is a chance for exception handling to diverge however.
Well, speaking of Visual C++ the C/C++ compiler and MinGWin
the gcc environment, yes, very different, not interoperable.
MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions.
Very inefficient. But heck, gcc doesn't support
__try/__except/__finally,
only C++ exceptions, and interop of C++ is often not great,
what with name mangling and all.

NT386GNU's OUTPUT uses a different runtime, unless you
  trim dependencies, possibly a different threading library,
  possibly a different windowing library. All this probably
  configurable. Again exception handling is a sore point in
  that it is the primary C runtime dependency of Modula-3.
  If you use Cygwin but say -mno-cygwin, that means
  you are targeting NT386. (and don't use pthreads or X Windows;
  behavior of exceptions/setjmp/longjmp TBD -- really, need
  to not use the -mno-cygwin headers in that case; I'll check).

Perhaps m3core.dll should export m3_setjmp/m3_longjmp..

Either one can do a cross build to the other.
Two cm3.exes, two sets of outputs, that either can produce.

NT386 can use gcc or the integrated backend.
  And the gcc it uses can be MinGWin or Cygwin. (theoretically and
probably soon reality)
 
NT386GNU can use either as well! (also currently theory, but a real
possibility)
  It isn't GNU tools, it is GNU runtime.

One small area with cm3 might fall down just slightly is that of
   cross builds where host and target have different naming
conventions.
   -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and
   I vaguely recall that cm3 ties naming convention to ostype.
   The appending of .exe is a target characteristics, but the others
are not really.
   Naming convention is really a host thing and not a target thing.

The config files are a mix of host and target information, mostly
actually host,
  except for the one line that says TARGET. Most of the target
variation is in cm3,
  which always can do any, and cm3cg (which might be nice to be
similar, but that's
  another matter and not likely to ever change, except when AMD64 is
the last
  architecture standing. :) )

If Windows had "rpath", then SL would be split between HOST_SL and
TARGET_SL.
As it stands, SL is HOST_SL.

Consider as well the various versions of Visual C++.
They output mostly the same, very interoperable.

Consider optimization switches. Host or target?
Consider version of gcc or Visual C++? Host or target?
Well, inevitably, the host has an affect on the target.
  If not the for the host, the target would not even exist.
  Bugs in the host produce bugs in the target.
  etc.

(And realize that Cygwin runs on top of an OS built with
a Microsoft compiler, so really there is interop, but sometimes through
a layer.)
 
So there's a risk of saying there is six+ combinations.
(host cygwin, host mingwin, host native) x (target nt386, target
nt386gnu) 
 
But generally the host is assumed not a factor.
 
I guess "LIBC" could be seperated into several options...
You could actually have code that needs one runtime or another, and
they could
link together, depending on what they do..
 
This is something I don't know if cm3 handles, or anything I have
seen.
 I should be able to build a static .lib, that includes some C code,
that imbues its
   clients with build time dependencies. Well, I guess #pragma
comment(linker) is this.

So the next tasks are roughly:
   Merge my NT386 and NT386GNU files.
   Switching on a variable such as backend mode.
 
   Introduce a "new" (old) NT386GNU file, perhaps more like what was
already there.
 
   Change NT386GNU back to Posix.
 
   Build NT386GNU.
 
oh, one more point...while these are two targets from cm3's point of
view, they are PROBABLY the same target to cm3cg
and so only one is needed. I have to check if configure differentiates
between i686-pc-cygwin and i686-pc-mingwin...
but I guess it should...
It might actually be profitable to have two bloated cm3cg.exe's.
And they should ship to \cm3\pkg\m3cc\target\host or host\target and
cm3 should know which to run.
Blech..four of them when one would suffice?
The detail being mainly what the paths to .libs look like,
unfortunate.
Possibly cm3 can bridge this gap using that "broken" feature that
symlinks libs into the target directory,
using NTFS hard links, if installroot and root are on the same
volume... (or symlinks on Vista).
Or maybe convert the paths as appropriate, hacky, but saves an extra
cm3cg.exe which is good to avoid.
 
(all the more reason to lump all targets into one file, so that the
host x target matrix collapses to just one axis, host; and
then you can write stuff in Perl/Python/Java/C# to collapse that to
just one, except for the underlying runtime/interpreter...)
 
Oh, cm3cg isn't the issue. It is always sitting in the correct
directory and reads one file and writes one file, no slashes.
The issue is gcc as the linker. Again, this is a host issue..and cm3 or
the config file definitely should do the translation.
 
 - Jay

From: jayk123 at hotmail.com 
To: m3devel at elegosoft.com 
Date: Mon, 21 Jan 2008 23:01:44 +0000
Subject: [M3devel] platform/build_dir is a big tuple?

Need to know the score, the latest news, or you need your Hotmail*-get
your "fix". Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
Climb to the top of the charts! Play the word scramble challenge with
star power. Play now! (
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080122/d4f10e2b/attachment-0002.html>