[Cmake] RE: [Dart] cDart anybody?

[Miller, James V (Research)]

Here's my take...

I think backward compatibility is one of our constraints.  For instance, 
I would like to rework some of the configuration file names but it will probably
require supporting both modes.

In the Tcl vs Python vs Java front, I think we found that Tcl provided the best 
tools for being able to spawn an executable, terminate a spawned job if it takes
too long, and get exit status information.  Obviously, all of these are doable
in C++ but it we be somewhat platform specific.


Response to Andy...

> Benefits?
> 
> 2. Handles spaces (all C++ code)

The spaces issue is really not a Tcl problem.  It is a problem with 
knowing what is a "path", what is a "executable", and what are the "parameters"
to the executable. Currently, these are not separated enough in Dart. I 
made a pass about 6 months ago so things like Purify, Scp, etc. could be
in paths with spaces.  I thought I had also addressed the issue with the 
project having a space in its path but maybe I didn't get all of those.

But again, it is not a C++ vs Tcl issue, it is a issue with separating
paths, executables, and arguments.


> 3. Simple installation (no tcl and you already need CMake)

Agree.  But Tcl on Windows is incredibly easy to install.  Tcl
on Linux is easy.  Tcl on Solaris, SGI, is slightly harder (actually 
have to type "make" :) but it is much easier than it was 5 years ago.

Now, we use Dart on a number of projects that do not use CMake.  So I think
it is important that Dart be usable without requiring the project be a CMake
project.  That does not mean that Dart couldn't be "in/with" CMake. Just that
Dart shouldn't rely on the project being tested being a CMake project.


Response to Ken...
> 
> 1) The client should not require any extra software. It should support
> being delivered as a binary. InstallShield etc... (sounds like this
> could be done for windows already?, If so then that would be an easy
> win)

Binary installations for common platforms could be done with the current
Dart.  The short putt for Windows would be to include a Tcl installation
inside the Dart installation.  A single InstallShield triggers all the
installations.  This works reasonably well.

However, to handle all the platforms in a standard manner, I would lean
towards looking at one of the Tcl compilers to generate a binary that 
could be distributed. I have never tried any of these tools but I assume
they would work for Dart since Dart doesn't do anything tricky like trying
to load additional DLLs.


> 
> 2) On less common systems where a binary isn't provided, building it
> should be fairly easy

Agreed.  This becomes a tradeoff between ease of client installation
and ease of developer installation.  If we use a Tcl compiler, then we 
just made it a little more difficult for the developers.  But developers
are smart people and should be able to handle it.


> 
> 3) The client should be firewall friendly (only use ports that are
> commonly available, I think that is already the case)

Absolutely. This is currently the case and why we originally chose to 
got ftp/cgi-bin.


> 
> 4) Handle spaces / short paths / network paths / etc (this would be
> nice, I tend to put most of my dashboards in directories with spaces
> to test CMake, so this hits me more than most.)
> 

I think we should be able to track these down and plug them as is.


> 5) The server should not need to have its memory limit specified

I agree here.  This is the limitation of using Java for the XSLT translation.
If the native XSLT translators reach the point where they handle the features
we need, we'll start providing native translators. It's been a while since
we checked on the status of the XSLT translators.

> 
> 6) Processing a Dashboard should not require more memory than 2X the
> size of its inputs (normally I would say this isn't an issue but in
> relation to item 5 it becomes more of a problem, this may have been
> fixed at one point I'm not sure)

About a year ago, we upgraded the XSLT translator to a newer version that
is smaller and faster.  We should look again to see if there is a newer
version.

Unfortunately, the current XSLT translation offers very little control
over how much memory is used. One of the C++ translators may allow us
to sacrifice speed for memory.


> 
> 7) It would be nice it the server did not need a checkout of the test
> software to run

Absolutely.


> 
> 8) Smaller fonts

I plan to look into what CSS magic I use to address this.  I think all the 
sites you mentioned previously explicitly use a "font=-1".

> 
> 9) Disk space management (this is an important issue to me) Both the
> client and server consume disk space until they run out. Some sort of
> built-in disk space management would be great (this is for both the
> client and the server) I'd like to be able to specify (let dart have
> 20 Gig for testing results and then start deleting/archiving/etc)
> 

Good point.

> 
> > I would like to propose this:
> >
> > 1. Write a real server in Java (or Python?)
> >    - use XML-RPC as the connection layer (only... no more
> > FTP/Perl hacks)
> >    - don't require the server to have a checkout of the source code
> >    - eliminate cron, have the server do the roll-ups,
> > perhaps as results come in
> 
> Sounds good. I don't know Java or Python very well but so far I have
> been concerned about Java's memory bloat (but I know neither language
> well so ...)
> 
> > 2. Run with Jim Miller's re-factoring of the client
> >    - Use Python with a class structure to allow better
> > adaptation of new tools
> >    - Python isn't the "cleanest" of languages eithor
> >      Java would be my first choice, but distribution is a
> > pain, i.e. no binaries, only JVM
> 
> I think binaries would be good, but I don't know the tradeoffs between
> Java/Python so again take it with a grain of salt.
> 
> > 3. Rewrite the configuration files to be in XML
> >    - using the tags, we can break out commands and
> > arguments, no more guessing about spaces!
> >    - much more flexibility than a "flat" file
> 
> I'm flexible on that one. I think we need to support backwards
> compatibility but other than that whatever format is best.
> 
> Thanks for the good work
> Ken
> 
> _______________________________________________
> Dart mailing list
> Dart at public . kitware . com
> http://public . kitware . com/mailman/listinfo/dart
>