Re: Ada package registry?

[Tero Koskinen <tero.koskinen@iki.fi>]

2.2.2016, 1.22, Randy Brukardt wrote:
> "Tero Koskinen" <tero.koskinen@iki.fi> 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