Re: Standard Library Interest?

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Marin David Condic wrote:

> Years ago in Ada83 there was an effort by (I think?) Richard Conn? It 
> was affiliated with some university - it may even still be out there. He 
> was assembling all sorts of Ada code and trying to classify it for easy 
> reuse. A noble effort. I think it suffered from a couple of factors: 1) 
> The "Not Invented Here" syndrome - which makes it tough for any library 
> (but can be overcome). 2) The general inconsistency from one package of 
> stuff to the next - no integration. 3) Often poor quality of what was 
> there - things might or might not even compile, much less run. 4) 
> Varying styles & interfaces - nothing you saw in one package was going 
> to be mirrored in another package. ) Lack of documentation - or at least 
> spotty and inconsistent. You might have the code but you might not be 
> able to figure out what to do with it.

Everyone wants something "ready to go". This isn't a bad thing, since
I like that too ;-)

But getting there is difficult, it seems. If I was to take on a package
integrator role, focusing only on the GNAT world (for example), here
are some of the challenges that I would face:

- Ada is not a preprocessed language, yet there must be some code
   tweaks for each environment:

   - Different pragma Linker_Options depending upon platform (for
     linker convenience)
   - C macro value insertion (by various means)
   - Some language constructs don't compile, due to version specific
     GNAT bugs.

   This is addressable with gnatprep, but it adds a layer of complexity
   to the task at hand (and maintenance). This adds some layer of
   complication when it comes to users reporting bugs (you must relate
   the installed source line back to the original "template" source).

- Some distributions must be distributed in original, unmodified form.

   This requires you to work out "patches" that can be applied at
   install time (not a show stopper, but it adds "work"). Actually, this
   is perhaps the best thing that can be done, but it does require extra
   effort.

- GNAT installation challenges:

   Different versions of GNAT have different *.ali file format differences.
   This one drives me crazy.  I am now in the midst of producing a
   APQ binary release for GNAT-3.15p, because I have discovered that
   my GNAT-3.14p binary release won't work for 3.15p users (win32).

   That means that I have to produce different binary installs for the
   same win32 environment, just to accomodate different
   flavours of GNAT. How many flavours of GNAT should you support?

   - Then add the never ending thrashing of changes from M$, on the
     win32 side.

- Platform related installation challenges:

   No registry in Linux/UNIX/*BSD. So different install scripts/processes
   must be tested and documented. Often shells differ in their support.
   Even the same shell, but different versions have various bugs that
   can get in the way (bash).

   - The biggest annoyance that I have on a *NIX platform, is where is
     the correct place to put Ada packages?   Where do all those *.ali
     files belong?

     It would be nice to have
     a "STANDARD" or "accepted practice" answer to this question.

     Should it be under /opt somewhere? The LSB never mentions Ada, that
     I am aware of.

     I use the GNAT environment variables ADA_INCLUDE_PATH/ADA_OBJECTS_PATH,
     but what if the user does not have these defined?  Then what?

     Should I use gnatls -v output to guide the install?

- Documentation: Libraries tend not to get used if they lack proper
   classification and documentation. For me, the first thing I look for
   is the answer to "why do I need this package/function?"

   So much documentation out there, fails to answer this basic question.

- TESTING. This one is big, IMHO.

   - The user needs confidence that it is "ready to go". The only way
     this assurance can be there, is that there are some tests that
     can be used to measure this in a limited way.  This is a major
     undertaking for some packages.

Just some points to ponder (I am not suggesting the idea is hopeless). ;-)


AS A SIDE NOTE, I wish that GNAT would allow you to package
all of those pesky *.ali files into a libever.ali.a archive file, using
ar. But GNAT would need to be enhanced to do this. Is Robert lurking
out there? ;-)

Warren.