[M3devel] platform/build_dir is a big tuple?

[Tony Hosking]

On Jan 22, 2008, at 8:29 AM, Olaf Wagner wrote:

> All this may be useful during development, but it is not really
> useful for a software distribution to our users, I think.
>
> Nobody will understand it :-( We need to keep things more simple.
>
> We don't need to support everything out of the box. Instead, we should
> offer some sensible default combinations of everyhing you describe.
>
> First of all: we don't distribute cross compilers (at least until  
> now).
> This is a special topic reserved for adding new platforms.

Precisely why I don't like many of the recent changes.  I don't want  
to build Windows interfaces and gorp for a non-Windows platform.   
Jay, can you *please* back these changes out?

>
> Runtime and compilers used do not necessarily need to be distinguished
> by target or build dir, in many cases different cm3.cfg may suffice.
>
> Until now, threading models are also no choice that needs to be
> visible at this level. There's one default model for every target,
> and the user can change it by recompiling.
>
> And if we should really agree that changing the target naming scheme
> is a good idea, we should
>
>  o use a systematic one with not more than 4 elements (better still,
>    3 (e.g. <arch>-<os>-<variant>))
>  o don't use cryptic abbreviations that will confuse most people
>
> Just my 2 cents,
>
> Olaf
>
> Quoting Jay <jayk123 at hotmail.com>:
>> 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   
>> temptingin 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, thoughit 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 commoncases 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 casingand   
>> 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 promptthe 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  
>> chosehow  to compile/link which are the main variables today.
>> and then decide about cygwin, but probably do like the above,   
>> sinceit'll totally share code with NT386 except the naming   
>> conventionsand the removal of the -mno-cygwin switch..
>>
>> I know this seems overly complicated, but it should be   
>> exposableeasily enough to users by hiding the choices, presenting   
>> three basic ones,and still allow all the obvious and perhaps  
>> useful  knobs, and iterating throughthe combinations, without  
>> creating a  combinatorial explosion of source filesor Modula-3 or  
>> Quake code.
>>   ...Jay
>>
>>
>> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22  
>> Jan  2008 10:48:56 +0000Subject: 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_mmmimmOk, I  have one more name here, and then a bit  
>> of a change, or a stronger  statement of something I had already  
>> said.NT386MINGNUOk, 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, targetingthe  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 MinGWinthe 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 witha 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   
>> couldlink 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 cm3cgand  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;  andthen 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.comTo: m3devel at elegosoft.comDate: Mon, 21  
>> Jan  2008 23:01:44 +0000Subject: [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.
>> _________________________________________________________________
>> Climb to the top of the charts! Play the word scramble challenge   
>> with star power.
>> http://club.live.com/star_shuffle.aspx? 
>> icid=starshuffle_wlmailtextlink_jan
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>