[M3devel] Hudson question

[Jay K]

It doesn't likely make a difference.
 

Before you needed Cygwin or Interix.
Now you need Cygwin or Interix, and probably Java.
Java will probably be a sticking point on various platforms,
but the gains are also very nice where it is available.
I see there has been work done on an assembly-free Java VM
since Sun open sourced their VM, so that promises increased portability.
(One wonders some about the Critical Mass VM).
 

Writing more .cmd isn't going to help anything imho.
It's just more hard to maintain code that someone
will have to maintain in parallel to Olaf's .sh.
Which is why I favor Python -- portable, no duplicated effort.
 
 
"Hard to main" as it, sure, it is easy to get started, but
what happens when you decide you need an array, or a hash table?
Or any of a number of basic programming constructs?
 Ok, I guess you have while loops, using goto.
 Local variables. At least that are strings. Everything is a string.
cmd has one or two surprisingly powerfuli features, such as for /f
and set /a. If you can't do your work with them, you can't do it.
sh is a bit more portable than Python, but not by much and
imho at too large a cost in maintainability/generality.
It still seems to me like a string based language that can't do much,
but I admit I'm not practised in it. (I am very practised in .cmd.)
 
 
You know, the fact that expression evaluation is in some mix of the "[" command
and maybe in sh itself. That people write if xxx true else yyy instead
of if not xxx yyy.
The fact that Solaris is different.
The fact that quoting is needed in various places.
Quoting always bothers me. It is hard to predict how many levels
of unquoting will be done.
I suspect cmd, sh, and Tcl are all in the same overly string based boat.
For example in Tcl, { } appear to have the same meaning as in C and C++, good,
but in fact they are escape characters, very wierd and bad.
 

Cygwin and Interix both probably work fine.
Someone just has to set them up and run them.
 

Consider Cygwin and Interix almost the same.
Interix is much faster, if you are calling fork a lot.
Cygwin is slightly more compatible with Linux/Posix.
 

Interix has a few ways in which is resembles Linux/Posix more though,
such as not using extensions on executables, using ".so", supporting
runpath.
 

I think with Cygwin 1.7, both it and Interix go to extreme
of supporting backward slash and colon in paths.
Interix actually ors in 0xFF00 to such characters but
it is transparent to Interix code. Or maybe that's what
Cygwin does. I don't remember. It is completely non
transparent and discoverable if you look at the results from Win32.
 

Interix probably a larger download, because the
part that is mostly "built in" is basically nothing,
just some infrastructure and very few utilities.
I don't think there is even sh or ksh.
Everything else is one large download.
 

On XP nothing is "builtin", there is just one large download.
"builtin" is on Server 2003 R2, Vista, Server 2008, etc.
 
 
(Oh, and Cygwin 1.5 works on Win9x, Interix only down to windows 2000.
But Cygwin 1.7 drops Win9x support, but maybe still works on NT4?)
 

 - Jay


----------------------------------------
> Date: Fri, 24 Jul 2009 18:17:29 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Hudson question
>
> Quoting Randy Coleburn :
>
>> Olaf:
>>
>> If we switch to Hudson, does that offer any improvement in the Windows arena?
>>
>> We haven't been able to get Tinderbox to work for Windows.
>>
>> I don't mind hosting something for Windows to do the tests if that will help.
>
> Well, yes and no ;-)
>
> Hudson itself should be as easy to install on Windows as on Unix,
> as it's completely written in Java. You just download the hudson.war
> file and start it with java -jar hudson.war. Java should be at least
> a recent 1.6 distribution. You can just try that and play around with
> the server if you like.
>
> The regression test scripts are all written in Bourne shell syntax,
> so you'd need Cygwin to run those again. There are probably a few
> quirks left to make them really work on Windows. Perhaps the Interix
> POSIX environment Jay has told about may be better suited, but I don't
> know.
>
> In the Hudson setup on birch and luthien I've used parts of the
> regression scripts for Tinderbox. If we want the test scripts to be
> the same on all systems, it may still be difficult.
>
> On the other hand, we could start with a much simpler setup on Windows.
> Begin with just one test job that checks out and compiles everything.
> That should be easy to achieve. I don't know if you can use the cmd
> scripts in Hudson on Windows, but I assume you can. If that works,
> we could start with transferring your build results to the Hudson
> server on birch. Or you could allow birch to control your Hudson
> installation as a slave server.
>
> Does that sound feasible?
>
> Regards,
>
> Olaf
> --
> 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
>