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!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: =?UTF-8?B?QmrDtnJu?= Persson Newsgroups: comp.lang.ada Subject: Re: CPAN style Ada repository Date: Wed, 11 Dec 2013 21:49:34 +0100 Message-ID: <20131211214934.690d2601@hactar.xn--rombobjrn-67a.se> References: <52976431$1@news.actrix.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: individual.net gCAZ4fXYeYa6XmUPpzqSTAkopKBkq66aYuflBDIj+I6pHJJ/1Y Cancel-Lock: sha1:kjSWM86i77LCA+XT/e3rFfbsuZU= X-Newsreader: Claws Mail 3.9.2 (GTK+ 2.24.22; x86_64-redhat-linux-gnu) Xref: news.eternal-september.org comp.lang.ada:17975 Date: 2013-12-11T21:49:34+01:00 List-Id: banjo wrote: > Would there be interest in a Perl CPAN style Ada repository? >=20 > Using the best ideas from Perl's CPAN, GitHub, Debian packages, > SourceForge, Savannah, and how Go uses git. >=20 > Using git versioning, bug tracking, mirrors, smoke-testing, > packaging standards etc, to archive, package, distribute > and promote high quality Ada modules. This might seem like a good idea, until one starts to realize the implications. I assume that you would want this repository to be usable on many different operating systems, and maybe with different compilers (because if you were planning to target only GNAT and Debian for example, then you'd simply make Debian packages instead of proposing a new repository). The Ada language itself is quite portable between operating systems and compilers, but how to get the Ada code compiled and installed is quite another story. There is no standard for how to invoke a compiler or how to link to libraries, no standard set of compiler options and so on. Different operating systems have different commands for making directories and copying files, vastly different filesystem layouts, and even differences in pathname syntax. GNAT project files do only parts of the job, and are specific to GNAT as far as I know. CPAN has it easy by comparison. There is only one Perl interpreter (probably because the language is such a hideous mess that it's impossible to write a compatible second implementation), so they don't need to worry about different compilers. I recommend packaging for one of the existing distributions instead. Come join us in Fedora, Debian or some other distribution of your choice. Version control systems, bug trackers, build servers, mirrors and packaging standards are already there for you (at least in Fedora), and the packages will be just as readily available to users as any other package. It may seem like duplicated effort to package the same software multiple times for different distributions, but it's actually not so bad. Packaging for one operating system is easier than packaging for many of them at once, so it's several smaller efforts instead of one big effort. I took part in the Gnuada project at Sourceforge for a while. There we tried to make RPM packages that could be built for both Suse and Fedora. Only two target platforms, very similar and based on the same package manager, and even that was enough to cause problems. One thing that would help considerably, and that would be surmountable, would be if developers of free Ada software could agree on some conventions for how makefiles should be written. Free projects usually have build systems made of makefiles and Gnat project files, but most of them are too inflexible to adapt to different filesystem layouts, support staging or allow compiler options to be customized. Packaging is slow when packagers have to figure out how each makefile works and often patch makefiles to get them to meet packaging standards. We could get much more libraries and programs packaged if developers would follow some conventions. Such conventions would need to work for mixed-language projects as well as pure Ada projects, and for both Gnatmake and GPRbuild. I recommend using the Make variable names from the GNU Coding Standards (https://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html)=20 and extending that with Ada-specific variables in the same style. Developers, please support LDFLAGS for linker options, and support CFLAGS if there is C code in your project. Stick to this naming scheme and use "ADAFLAGS" for Ada compiler options, "GNATBINDFLAGS" for Gnatbind options, and so on. Support the GNU standard directory variables so that your software can be installed in different systems with different filesystem layouts: prefix, exec_prefix, bindir, libdir, libexecdir and all the others as appropriate for the types of files that your project installs. Extend with "gprdir" for GNAT project files and "alidir" for ALI files. Install ALI files in a library-specific subdirectory of alidir, just like source files go in a subdirectory of includedir. Support DESTDIR so that packagers can install to a staging directory and don't have to build packages as root. Writing such a flexible makefile is of course nontrivial work that you don't want to do over and over. You can avoid most of the work by using Comfignat (https://www.rombobj=C3=B6rn.se/Comfignat/). Comfignat gives you all of the above, except that limitations in Gnatmake's and GPRbuild's command line syntax prevent it from automatically supporting LDFLAGS and GNATBINDFLAGS when libraries are built. This approach covers only those operating systems that are Unix-like enough to have Make and basic commands such as cp and mkdir, but that should include OS X, and hopefully even Windows with Cygwin or MinGW is Unix-like enough, so it's a decent set of target platforms. (And none of the above prevents you from also supporting some other platform by other means.) Bj=C3=B6rn Persson