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!gegeweb.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: Fri, 5 Feb 2016 19:25:56 -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 1454721957 7865 24.196.82.226 (6 Feb 2016 01:25:57 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 6 Feb 2016 01:25:57 +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:29373 Date: 2016-02-05T19:25:56-06:00 List-Id: "Tero Koskinen" wrote in message news:n92uia$do6$1@loke.gir.dk... > 2.2.2016, 1.22, Randy Brukardt wrote: ... >> 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. :) Yes, surely. :-) > 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. But you are the shining exception to the rule. I think you and one other author are the only ones that are currently trying for portable Ada code; the vast majority don't seem to care or don't know how to do it or something. It would help if there were more tools for enforcing portability, as well as some way of expressing assumptions. (A package manager would help there, of course.) [What I mean by expressing assumptions is that it's unlikely that any real Ada code would really run anywhere. I've been having fun with Gautier over his "unconditional portability" claim, as one only needs a single counter-example to disprove the claim. After a few obvious problems with the choices of Janus/Ada were worked out, I pointed out that his types wouldn't work on our old U2200 compiler (as that was a 1's completement, 36-bit machine). He decided quite reasonably not to worry about that, but that means in his case, that means his code is "unconditionally portable" so long as your target supports 32-bit integers and is 2's complement. That might be 99% of machines, but its not quite unconditional.] ... >> 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. That's trivial: run the compiler's Make. The issues I was thinking about is dependencies on things like OpenSSL. One could manage to automate that sort of dependency on one system fairly easily, but to do it on all reasonable targets (various Windows versions, Linux distributions, OS X, FreeBSD, etc.) is a combinational explosion (given that some sort of Ada compiler configuration is also involved - which is different for every compiler and often for different targets as well). That's the problem that other people here were talking about. It probably isn't the problem YOU were trying to solve - what you described is perfectly reasonable. (I'm dubious that it would be that useful for Ada, since compilers already include good build tools, and little more is needed to use third-party stuff -- but if it helped determine what is and is not portable, that certainly would help the non-GNAT users out there.) Randy.