Re: CPAN style Ada repository

["Björn Persson" <bjorn@xn--rombobjrn-67a.se>]

banjo wrote:
> Would there be interest in a Perl CPAN style Ada repository?
> 
> Using the best ideas from Perl's CPAN, GitHub, Debian packages,
> SourceForge, Savannah, and how Go uses git.
> 
> 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) 
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örn.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örn Persson