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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Mart van de Wege Newsgroups: comp.lang.ada Subject: Re: Ada package registry? Date: Sun, 31 Jan 2016 16:52:42 +0100 Message-ID: <86a8nlg305.fsf@gaheris.avalon.lan> References: <02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net v49F2I4ceQSULKK7QpK4Hg1w/lE47hSbtZ5HVy4pQL4FJ0evIL X-Orig-Path: gaheris.avalon.lan!not-for-mail Cancel-Lock: sha1:zNCLNyYmBA9YJLCigwvPco6FKOI= sha1:ttIz3vasrAxXKi6CA8K3uT16p0g= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Xref: news.eternal-september.org comp.lang.ada:29304 Date: 2016-01-31T16:52:42+01:00 List-Id: "Dmitry A. Kazakov" writes: > On 2016-01-30 23:14, Tero Koskinen wrote: > >> Usually the repositories are maintained in "wiki"-style and anyone can >> update the package details (within certain limits). This causes some >> security concerns/implications, but in general there is not that much >> abuse and the repositories work well enough. >> >> The package repository management tool is used like this: >> >> $ language_package_mananager install X >> Downloading dependencies for 'X', please wait a while... >> Downloading X... >> Package 'X' installed! >> $ > > Yes, the problem is to have it working. > >> Once the package (a library usually) is installed (to your home >> directory), you can link it to your program and simply use it. > > No, that the point. It cannot be installed in your home directory. It > must be in the directories mandated by the target system > policy. E.g. for Debian Linux: > > https://people.debian.org/~lbrenta/debian-ada-policy.html#Files-provided-by-the-_002ddev-package > Nope. I am most familiar with Perl, so I shall use that as an example throughout. Installing CPAN packages through the CPAN manager requires you to either adjust the PERLLIB environment variable, or to add a 'use lib' pragma to your code. Managing ADA_INCLUDE_PATH in an Ada equivalent would not be much different. Plus, as in CPAN, if the libraries are laid out along a standard policy, it would be easy to provide tools to build system-local packages, like dh_make_perl does for Perl on Debian. >> 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. > > I guess these are scripting languages and pure packages having no > access to the system environment otherwise than through the language > run-time. There is no problem to do same for GNAT. That is not Ada > case. Most Ada packages do access platform-specific non-Ada > libraries. Pure Ada packages face no problem, if gpr file is provided. > This is not unique to Ada. Perl also has packages that require non-Perl libraries to be available, like XML::LibXML and Text::CSV::XS. The first has a dependency on libxml2, the second brings its own C code that must be compiled and then accessed from the Perl module. In both cases a hard build dependency on a working gcc environment exists; it is the end-user's responsibility to make sure it does exist and that the proper header files for the dependencies are installed. Really, this is not a new issue. It is solvable, if you let go of the NIH mentality. Mart -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source.