>
> Perhaps "really expensive", or "hard to achieve". It is _not_
> "unavoidable". I hate all absolutes :).
*** I hate absolutes too, except for my depts (Abs(-whatever) is Whatever)
so my dept would be cleared hhehehe...

>
> Why would that happen? The Gnu tools manage many platforms with no
> version problems. Well, some poorly-supported platforms may take a
> while to catch up to the latest version, but "gcc 2.8.1" means the
> same thing on all platforms.
>
*** I agree here.  perhaps we could keep a history somehwere of versions
that have been released before so that they could access them....\archives
folder in each package's folder, or something? if one really wants to use a
previous version.

>
> I find Aunit to be a good unit test framework (see
> http://savannah.nongnu.org/projects/grace/ for a working example).
>
*** I heard of that one, it does look pretty good as a testing unit...but I
wouldn't limit it to one as they are more than one testing engines that do a
good job...all we really need is to know that it has been tested and the
results of that test and I would be contended.

> We could require each top-level package to provide a Version function,
> that returns a string. Also follow the Gnu convention of including
> that string in the tar.gz file name for distributions.
>
*** that would and could work :-).   or at least a file with a version
history (with the top most line being the most recent version ... something
clear somewhere to say that "this is the one you want"/

>
> More important are things like standard names for common operations;
> do we "Add" an element to a container, or "Insert" it? That's a major
> problem for integrating existing code. SAL attempts to do this, but
> doesn't fully succeed.

*** I second that motion, probably because of my non ada background (shame
on me :-).  but if we consider "polymorphism"  indeed a true library should
use consistent names for similar functions and procedure.  again do we Open
a file or do we Load a file, do we Save or Store a file?  anything in the
library that saves a file (log file, report file, any file at all) should
use the same name.

*** likewise any package/library that has the ability to display itself on
the screen should have standard names ... do we show the form, display the
form, do we use a property like Visible set to True, pick one and stick to
it. :-).

*** Definitaly reduces the learning curve of the whole library this way.  I
have to agree with that :-).

>
> But it's really not reasonable to define unit tests at this level.
> Many unit tests require auxiliary packages, which should _not_ be
> children (see SAL for examples). Providing a Makefile that runs the
> tests and produces a pass/fail is much more reasonable.

*** How about an independant file for the testing?  as in
you have SAL and all its ramifications which represent the package/binding
whichever it may be.
and you have SAL_Test which would be a program that with's the SAL library
and performes the tests?
or somekind of standard.  maybe based on folders too (sorta like boost
library).
\src        <-  has the source code of the package itself (adn sub packages.
\test       <-  has source and/or binaries of the SAL_Test program.
\demos  <-  for demonstration programs of what the unit can do
etc etc.  maybe a  \docs for documents (which should be in one format only
somthing platform independant like HTML perhaps).

and the list goes on :-) for whichever and depending on the type of library
and/or binding.



>
> Hmm. I guess you mean one package depends on specific versions of
> other packages, and you want to check that at run-time (or better,
> compile time). That problem is solved by tools like Redhat Package
> Manager (rpm); it's a big problem, and we should not try to invent new
> solutions.

*** I second that motion.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com