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!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: Tero Koskinen Newsgroups: comp.lang.ada Subject: Re: Ada package registry? Date: Fri, 5 Feb 2016 21:52:44 +0200 Organization: JSA Research & Innovation Message-ID: References: <02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com> NNTP-Posting-Host: 37-33-27-40.bb.dnainternet.fi Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: loke.gir.dk 1454701962 14086 37.33.27.40 (5 Feb 2016 19:52:42 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 5 Feb 2016 19:52:42 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:29365 Date: 2016-02-05T21:52:44+02:00 List-Id: 2.2.2016, 1.22, Randy Brukardt wrote: > "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. NetBSD's pkgsrc should run on multiple platforms (all *BSDs, most Linux distributions, not sure about OS X or Windows) and support multiple programming languages/build systems. And if you want to support multiple host *and target systems* you could always check how OpenEmbedded/Yocto/bitbake combo is doing things. Of course, pkgsrc and OpenEmbedded are little different from the language (implementation) specific build systems, but they are still pieces of software which install a library (with dependencies) for you (under your $HOME dir) when you type "$my_package_manager install". > 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. I think you are forgetting who you are replying right now. :) Most of my Ada software compiles nicely with other Ada compilers (Janus/Ada, ICCAda) and I don't think it would be impossible to add Janus/Ada or ICCAda support to the package repository tool. You just need to make sure you don't try to compile Ada 2005/2012 code with Janus/Ada, which supports only Ada 95. >> 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. The package repository/tool which I am thinking about, would be only for open source projects/libraries/applications. Open source developers usually use only open source version control systems (cvs, subversion, mercurial, git, darcs, monotone, and fossil) and there are existing practices how to interface with them. Also, old-fashioned zip/tgz release package (fetched over http/https) is easy to support. What comes to installation methods, the $language community usually provides enough pressure and shaming to make the rogue project to follow the rules or to provide an installation method which is easy enough to integrate into the package management system. > 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. Not sure what sort of complexity you are thinking about. Just iterate through the dependency chain and build one dependency at time using the selected Ada compiler. When building one package, link the dependencies, and be happy. If there are C language libraries involved, call gcc or Visual C, and continue as usual. ... Building the package repository and related tool might take a lot of wall clock time, since the amount of volunteer Ada programmers with free time is limited, but I don't really see any blocking technical problems. And if there are any, I think then it is time to start making adjustments to the next Ada (or Ada compiler implementation) version! Yours, Tero