[Cmake] RE: [Dart] cDart anybody?

[Andy Cedilnik]

Though I agree with almost everything you said, I do have one major
reason for suggesting cDart. It does not rely on Tcl. It actually does
not rely on any other program. Yes, most of the systems today come with
Tcl,Python, ... but. Please try this just for fun. Go to a remote
location, where they have an old Sgi or Sun or something, and you want
to setup a Dart client in a limited amount of time.

			Andy

On Thu, 2002-09-12 at 08:51, Blezek, Daniel J (Research) wrote:
> First off, groking a few files to execute some tests is about 10 lines of any reasonable scripting
> language, and much more difficult w/C++, IMHO.  I don't feel that C++ will handle spaces in filenames
> any better that Tcl does.  It's just a matter of being careful coding: since Dart was done in an
> Extreme Programming manner, and handling spaces wasn't a huge deal at the time, it shouldn't be
> terribly hard to go through the entire body of code to handle them better.  A MAJOR part of the
> problem is the hacks we needed to do parsing the Visual C++ command lines to execute the sub-projects
> conscutively to handle VC++ stopping at the first error ( unlike make -k ).
> 
> So I very much resist re-writing Dart in C++.  However, since writing the first incarnation of Dart,
> I've become much more facile w/Python, and have been impressed with it.  While I don't view having
> Tcl as a major hurdle for people, I do see the advantages to having a binary distribution.  We
> certainly can compile Tcl into C/C++ code, expending only a little effort, but that is not really the
> question here.
> 
> Making CMake bigger and badder by dumping Dart into it isn't the solution.  Dart was explicitly
> designed to be completly independant of CMake.  This is for the betterment of both tools.
> 
> Rather than jumping to a full re-write based on some configuration complaints, (Andy) why don't you
> publish them to this list and we can see if we can address them.
> 
> 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
> 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
> 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