[M3devel] FW: Hudson question

[Jay K]

> 1. CMD comes with Windows out-of-the-box. No extra config/install is required.

 
So does JScript. If we must write Windows-specific scripts with no extra install dependency, I recommend it instead. I might try rewriting the scripts in it soon to demonstrate.


> 2. I want to be able to launch a CMD window and use the cm3 command line tools
> to build  Modula-3 packages.
> I also want to be able to run Modula-3 programs without need of
> any other tools except what comes with Windows by default. Now the
> latter isn't exactly possible if you are dependent on 
 
 
Agreed and not necessarily contradicted.
You need CVS to get the current Modula-3 source, but not to use it.
Where is the line?
 
 
> the .NET framework, but most systems have .NET anyway because Microsoft
> has pushed it out through online updates.
 
How is the .NET framework relevant?


> 3. I continue to experience problems with cygwin, python, etc. because the setup in
> each  is slightly different and there are dependencies that are not obvious.
 
 
Let's work on this? What are the errors? I've installed them each many times on many computers with no problem.
One problem you might hit is that you might have both Cygwin and native Python.
Start out with just one or the other.
 
 
> If you succeed in installing cm3 using cygwin, it isn't always possible to build/run 
> packages from CMD.
 
 
Why not? The only reason I can think of is that Cygwin .dlls/.exes are dependent on cygwin1.dll, so that /might/ be needed in $PATH.
 
 
However the use of sh is separate from the use of the NT386GNU platform.
You can launch native NT386 cm3.exe from Cygwin sh.
If you use Cygwin sh to build NT386 cm3.exe, the resulting cm3.exe has no Cygwin dependency.
 
 
> I haven't been able to get the python scripts to work for me, despite installing python.
 
 
Let's work on that?
 

> 4. CM3IDE launches the native shell to run the cm3 command line tools.
> On Windows, this shell is CMD. We need to preserve this functionality.
 
There is no need for CM3IDE to launch any shell at all.
Why does it?
You can just run stuff with CreateProcess and cmd (nor sh nor Python) is not used.
  Just because a console app runs or a console window comes up, does not imply cmd is anywhere.
You do need a cmd wrapper if you use, e.g. redirection, on the command line.
Things like system() tend to use cmd.
And the Modula-3 wrapper libraries might use cmd.
But you really don't need any shell at all.
 
 
I would not advocate any sh or Python wrapping. Adding sh really slow things down.
 
 
Plus, Olaf has provided q_exec or such that efficiently emulates things like redirection.
 

> 5. I have provided various CMD scripts in the repository and I've been
> keeping these up-to-date. I don't mind continuing to do this.
 
And the Tinderbox and Hudson stuff?
I'm hypocritical in that I don't want to use Olaf's sh either and have largely duplicated it. However I have used a more portable/readable/writable language.
I also haven't (and might not) finished dupliating the .sh.
I'm not sure.
You know, "soon" I should try one or more of:
 Old Tinderbox/sh stuff on Windows.
 New Hudson/sh stuff on Windows.
 Either of above but having rewritten .sh in .cmd or py.
 
 
Basically the story was, I was on vacation with a Mac.
I needed/wanted changes to the .sh but was unwilling to work on .sh.
  It is cryptic and despite years of slightly trying, I can't seem to get the hang of it.
  And then I fear that anything I write will only work one OS.
  I read through the autoconf manual how to write portable sh. There are like 100 wierd rules and caveats. I can only remember a few.
 
I had my choice of languages. Being somewhat experienced with Perl and really not at all with Python, I started using Perl. But immediately I hit the "array of hashtables or whatever" problem -- it is not obvious in Perl, though always possible, to build nested data structures. So I switched to Python and have been very satisifed.
 
 
> 6. For this next release, I can build either a CMD script for the install, or build an installer program (EXE). I am volunteering here.

 
I commited working automation to build an .msi.
It could use some polish though.
The licenses are all basically concated together, with a heading between each one (Olaf, I think my automation is actually ahead of yours here, the packages I build have more of the licenses, and there are so many, I put them in their own directory.) and there are is min.msi and std.msi, no internal package breakdown, and they don't create a start menu shortcut or help with finding cl.exe/link.exe yet. I would like to add a shortcut (where $PATH is set) and improve the area of finding cl.exe/link.exe, though this is probably best done by replication my existing pylib.py code in either Quake or Modula-3.
 
 
I investigated a number of options for how to build the setup.
I had never previously built an .msi, nor it follows, used Wix.
I tried many alternatives, but .msi with Wix seemed to be the fairly clear winner.
I can detail what I remember of my experiences.
  IExpress was a surprise, but ultimately seemed too limiting, including wrt number of files.
  Another .msi builder was and still is promising.
  NSIS was promising but I think wasn't automatable, I forget, and seems very wierd if you do want to customize the experience.
 
 
I think there is some chance we could write our own. Somewhat like cminstall but without the extra extraction step before running.
 

> 7. Whatever automated test environment we provide on Windows must work in the
> native shell in order to prove that stuff is working in that shell. If you use cygwin
> or some other shell, that doesn't mean it will work in CMD.
 
 
That is a fine line.
Not necessarily true, but easier to prove true the other way around, granted.
If you don't use Cygwin at all, then definitely the stuff works without Cygwin.
If you do use Cygwin, the waters have become perhaps muddied and you have to analyze to theorize if it works without Cygwin and probably can't prove it.
 
But still there is plenty of room to use Cygwin or Python and still have the results not depend on them. They are "just" ways to automate (aka script).
 
Do the tests work outside Hudson? Outside Tinderbox?
Well, it is not too difficult to run them outside either.
Do they work outside the .cmd wrappers?
 
Perhaps as well we should strive to port all/many of the "scripts" to Modula-3 or Quake?
Quake is fairly easy to read/write and of course portable. It is certainly more general than .cmd, though I think it fails at providing "nested data structures", because it does some "flattening".
 
 
Modula-3 is obviously general purpose. :)
 
 
This dichotomy between "scripting" and non-scripting languages has long bugged me.
The popularity of "scripting" languages, here and in the wider world, seems to indict the non-scripting languages as somehow inadequate.
 
I understand the guidance -- "pick the right tool for the job".
But there is also guidance -- "don't have too many different tools; don't have a different tool for each job".
 
If Modula-3 (or C or C++ or Java) aren't right for some job, maybe they need improving????
Maybe. Honestly, I think part of my problem is lack of familiarity with the Modula-3 libraries. And also that they may not be adequate, but Olaf's sysutils helped open my eyes a little. I find the libraries I'm most familiar with, of course, are the ones I write myself. :) Also the ones I like the "feel" of. Modula-3's libraries often hit me kind of the wrong way. I understand, e.g. the need for a portable path library, but this terminology "addhi", "remlo" is foreign to me. In every environment I'm in, I write the RemoveLastPathElement, GetLastPathElement, etc...
 
 
 - Jay