[M3devel] FW: FW: Hudson question

[Jay K]

[truncated again]


----------------------------------------
> From: jay.krell at cornell.edu
> To: rcoleburn at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] FW: Hudson question
> Date: Sat, 25 Jul 2009 01:28:13 +0000
>
>
>> 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
>