[M3devel] multi arch installs?

Jay jayk123 at hotmail.com
Fri Mar 7 08:57:03 CET 2008


background:
Windows has $PATH and $PATHEXT.$PATHEXT is used by the usual command line -- cmd -- to help find "executables".
On one of my systems:
C:\>set pathPath=C:\Python25\;C:\Tcl\bin;C:\Perl\site\bin;C:\Perl\bin;C:\Perl\bin;c:\ruby\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\QuickTime\QTSystem\PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.RB;.RBW;.tcl;.py;.pyw
(oops, I'll go clean it up..)
"Executables" are not just .exes.
The commands ftype and assoc combine to enable running "anything", based on extension.
For example:
C:\>assoc .exe.exe=exefile
C:\>ftype exefileexefile="%1" %*
C:\>assoc .js.js=JSFile
C:\>assoc .vbs.vbs=VBSFile
C:\>assoc .py.py=Python.File
C:\>assoc .tcl.tcl=ActiveTclScript
C:\>ftype activetclscriptactivetclscript="C:\Tcl\bin\wish85.exe" "%1" %*
C:\>ftype python.filepython.file="C:\Python25\python.exe" "%1" %*
C:\>ftype jsfilejsfile=%SystemRoot%\System32\WScript.exe "%1" %*
C:\>ftype vbsfilevbsfile=%SystemRoot%\System32\WScript.exe "%1" %*
If you ignore the need for executables to have extensions, this provides much ofthe feature of Unix where any file is executable, possibly via a specified interpreter.It is better and worse.It is worse in that extensions are needed.It is better in that files don't have to give the possibly system-specific pathto their interpreter.It is worse in that files cannot give the path to the interpreter.
It is worse in that it is a feature of the command line interpreter, instead of lower layers (kernel) as I believe on Unix.
Now, I have a small problem of convenience.And you all MIGHT have a "problem" of "What is Posix?"
My c:\cm3 contains a mix of NT386 and NT386GNU files. c:\cm3\pkg\cm3\NT386\cm3.exe  c:\cm3\pkg\cm3\NT386GNU\cm3.exe 
ok
 but then what is c:\cm3\bin\cm3.exe ?
Currently it is the most recently shipped file.
For the case of .dlls, I have enabled "colocation" by changing NT386GNU .dlls to end in .so.So I have:
  c:\cm3\bin\m3.dll    c:\cm3\bin\m3.so  
Probably this should be libm3.so and probably will be some day.
I would a system whereby somehow the two targets can coexist better.
Perhaps I should just suck it up and have c:\cm3\nt386 and c:\cm3\nt386gnu.Perhaps.
 
Quick experimentation shows that you can have an "empty" extension.
  set PATHEXT=.;%PATHEXT%    cd \cygwin\bin  copy ls.exe foo    .\foo  
 => It works. 
You don't actually have to do anything with assoc and ftype. Oops. I didn't have to bring that up.
The order of %PATHEXT% varies.
So, the proposal is, in the interest of killing two birds with one stone, neither of whichwas necessarily even alive at the start, is that NT386GNU use no extension for .exes.
 \cm3\bin\cm3 is NT386GNU  \cm3\bin\cm3.exe is NT386 (or NT386MINGNU) 
I started thinking about this partly because "Services for Unix" makes .exes with no extension.And because I suspect the handling here in Cygwin is hacky.There is various code such that if someone looks for "foo", they might find "foo.exe" instead.
Upsides:  "It works".
 
Downsides:  "foo" used to resolve via %PATH% + %PATHEXT% search..and it still does, but putting  . at the start will find foo where foo.exe was more common.
  It is not general. This scheme does not enable any other "multi arch" install.
 Alternate proposal with a question:   How should "multi arch" installs be achieved?   Probably via making \cm3\bin\foo on Posix and \cm3\bin\foo.cmd on NT that somehow   sniffs its environment, perhaps with uname, and then runs \cm3\pkg\foo\?\foo (or foo.exe)  
  Upsides:     It works, at least for executables.     It is more general than my previous suggestion. 
 
  Downsides:     Extra processes created.     What about .dlls/.sos?  
 Maybe nobody cares? 
 I find the idea of one unified file system/archive that works on "everything" fairly compelling.  Yeah, it's big. Yeah, it's slower to install. But it means one download can be had  independently of platform. 
Maybe simply \cm3\platform instead of \cm3?
  upsides:     it works      is general      no new mechisms invented!   downsides:     none?     too boring? :)      \cm3\platform\pkg\foo\platform is redundant.     Less able to do "cross" scenarios that I'm using a lot lately, where NT386 and NT386GNU can build each other?     Not clear. Probably just a matter of $PATH and $CM3_INSTALL not coinciding.
   cm3 -ship could see if CM3_INSTALL ends in "\platform" and in that case not put in the second instance,     but this possibly asking for trouble. Probably a bunch of code would have to learn about this.
   Just live with the duplication of "platform", in the unusual situation of a "multi arch" file system? 
 
Maybe there is nothing to do here.
 
The matter of what the file extension should be on NT386GNU perhaps is a different matter, left up to the hypothetical users of NT386GNU (not me).
"What is Posix?" Executables with no extension? Or don't care? Cygwin usually uses ".exe", but of course Cygwin bash allows running stuff with "shebang".
Microsoft/Interix "Services for Unix" puts no extension on executables. I found that a bit impressive, maybe worth striving for, and then surprisingly easy.
I am almost surprised Cygwin doesn't do this. I don't know if putting "." in $PATHEXT is any worse than adding \cygwin\bin to $PATH.
"If it is good enough for Cygwin, it is good enough for CM3/NT386GNU users?"
 
I am not proposing extensionless executables for NT386. That would just be considered wierd.
However the "wrapper .cmd" files, maybe.
 - Jay
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080307/b85cbfa7/attachment-0001.html>


More information about the M3devel mailing list