From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88ed72d98e6b3457 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-09 10:31:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn14feed!wn13feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? References: <3F7F760E.2020901@comcast.net> <3F8035B0.7080902@noplace.com> <3F816A35.4030108@noplace.com> <3F81FBEC.9010103@noplace.com> <6Ingb.30667$541.13861@nwrdny02.gnilink.net> <3F82B4A4.5060301@noplace.com> <3F82F527.3020101@noplace.com> <3F836447.1000800@noplace.com> <3F855056.5020606@noplace.com> In-Reply-To: <3F855056.5020606@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 09 Oct 2003 13:16:20 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1065719755 198.96.223.163 (Thu, 09 Oct 2003 13:15:55 EDT) NNTP-Posting-Date: Thu, 09 Oct 2003 13:15:55 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:547 Date: 2003-10-09T13:16:20-04:00 List-Id: 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.