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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada package registry? Date: Mon, 1 Feb 2016 17:22:28 -0600 Organization: JSA Research & Innovation Message-ID: References: <02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1454368949 28648 24.196.82.226 (1 Feb 2016 23:22:29 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 1 Feb 2016 23:22:29 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:29316 Date: 2016-02-01T17:22:28-06:00 List-Id: "Tero Koskinen" wrote in message news:n8jcj4$uus$1@loke.gir.dk... ... > People using other programming languages have managed to create > these package repositories, so it is a shame if Ada programmers > cannot manage to do the same. Not really. People using other programming language *implementations* have managed it. I see no evidence that it is possible to build such a thing that works with multiple implementations, running on multiple host and target systems, with different policies for installation, different project management facilities, and so on. > You of course need to solve many problems related to this domain, > but they are already solved by others, so one should be able to > copy the design and just do the Ada implementation. That wouldn't be an *Ada* repository. It would be a *GNAT* repository! There might be use to such a thing, but call a spade a spade here: don't insult those who use Ada, but don't exclusively use GNAT, by calling such a thing an *Ada* tool. > On the other hand, one could think that the package management > systems provides by Linux distributions and BSD operating systems > are enough. But generally, these are not that flexible. For example, > the language specific package managers allow one to install multiple > versions of the packages at the same time and the code can be even > taken from the version control directly. Which was my previous point: in order for that to work, you have to insist on package authors in using a specific version control system, specific installation tools, and most likely a single Ada implementation. A lot of authors are not likely to change their methods of working to use such a system (or have the time to develop complex installation schemes), so you're going to end up with a (smallish) subtest of available libraries. Which would be actively harmful for the future of Ada (or GNAT, if you prefer) - it would appear that there is a lot less available than there really is. I note that for "simple" libraries: those that use just Ada and/or target OS facilities, distribution simply by source code works well. For instance, we distributed Claw that way -- we provided a special main program that was designed to ensure that an Ada compiler's build tool would completely construct the library. Use gnatmake or corder or whatever did the trick. If one wanted to set up a separate project, one would use the tools of the implementation to do that (but it's not necessary). (If the user doesn't understand how to use the compiler's build tool, they need to understand that before doing anything in any case, they're not ready to build *anything* in Ada.) For more complex systems that need other libraries, I doubt there is any sensible solution. Unless you're planning to abandon Ada's portability between implementations -- not of much value, IMHO. Randy.