Re: CPAN style Ada repository

[Jacob Sparre Andersen <jacob@jacob-sparre.dk>]

banjo <banjo@actrix.co.nz> wrote:

> Would there be interest in a Perl CPAN style Ada repository?

Something like it, yes.

I have earlier discussed the subject with Thomas Løcke and Kim Rostgaard
Christensen in terms of the tools and infrastructure provided with the
Go programming language from Google.

Step one must be to decide what the purpose of the project is.  Some
possibilities:

a) Make it easier for newcomers to Ada to get started.

b) Make it easier to find and install Open Source libraries and
   applications written in Ada.

c) Document how (and how well) Open Source libraries and applications
   written in Ada build and run on various platforms and with various
   compilers.

d) Advertise the existence of other Ada compilers than GNAT.

e) Survive, grow, and encompass all published Open Source Ada source
   texts.

I know that not all contributors to this thread weigh these purposes
equally, but I think they all have value for the Ada community as a
whole.

Based on these objectives I propose:

1) Make a "first download" package, which provides (or downloads or
   validates the existence of) a compiler and a client (developer) tool.

   (Like for Go.  A step towards objective a.)

2) Besides the "first download", the system provides "projects", which
   may be libraries, applications or a mix of both.  (A "library" is
   basically a project without any non-test executables.)  The
   collection of projects can be queried and downloaded through the
   client tool.

   (A step towards objectives a and b.)

3) All projects are required to have some built-in tests.  As a minimum
   there should be test applications which ensure that all compilation
   units in the project sources are compiled.

   (A step towards objective c.)

4) Support multiple compilers.  Tero Koskinen has both GNAT, Irvine
   ICCAda and Janus/Ada on his <http://build.ada-language.com/> site, so
   it should be possible.

   (A step towards objectives c and d.)

5) Make it easy for developers to submit new projects to the system.

   (A step towards objective e.)


Refining the proposals above:

6) Each project needs some build rules.  As we want to support multiple
   compilers (proposal 4), it makes sense to have a very simple
   (proposal 5) build rule format, which then can be compiled to build
   rules for the various supported compilers.

   The minimum requirements for the build rules might be as simple as
   three lists:
    - Which projects this project depends on.
    - Which applications are to be generated by this project.
    - Which test programs are included in the project.

7) If an up-stream project is parametrised (or uses different sources
   for different hosts/compilers/targets), our view of it is multiple
   unparametrised projects.  This will allow for simpler build rules
   (proposal 5 and 6) and at the same time simplify testing (objective c
   and proposal 3)

----------------------------------------------------------------------------

The following is a collection of various ideas for the project on a more
practical level.  These ideas are not (yet) tied properly to the
objectives listed above.


General:
========

- Source-only projects - Skip the whole problem of generating dynamic
  libraries.  Not many systems will have more than one application
  running using large parts of the same Ada library.

- Use ISO dates plus a single latin letter as version identifiers for
  projects.  This will allow about one version per hour per project.  Is
  this an unreasonable limit?

- Project naming: As Ada identifiers with the extra constraint that they
  can't end in "_" & Possible_Version_Identifier or "_" &
  Possible_Version_Identifier & "_test".  (Other constraints?)  This is
  to allow GPR files to reference either the "head" version of a project
  or a specific revision.

- Project parameters:

   + Build rules.

   + Version control link.

   + Provides: API ID's.

   + Dependencies: Both other projects in the system, API ID's _and_
     operating system specific dependencies.

   + (plus revision information)


Client (developer tool):
========================

- Keep track of which projects the developer has fetched explicitly (and
  which specific versions have been requested, where that is relevant)

- Keep track of the dependencies of the installed projects, and make
  sure they are fulfilled.

- When updating; only pull the newest versions of previously requested
  projects, when the developer hasn't asked for a specific version or
  has asked for "head".

- The Go command-line tool has (at least) the following operations: get,
  build, test, run, install.  I'm not sure I care about "run", but
  "drop" (sort-of "uninstall") and "select-compiler" (as we want to
  support more than one) would be nice additions.

Service:
========

- Generate new project versions from up-stream commits automatically.

- Test new project versions automatically as they are generated.

- Only release project versions which pass the tests on at least one
  host-compiler-target combination.

- It would be nice if it automatically could test which revisions of the
  dependencies of a project result in a working (test-passing) system.

- Should we host copies of the sources of the projects as a part of the
  service?  Jim Kimball doesn't like to do it, but I like the idea of
  fetching sources and build rules from a single location.

----------------------------------------------------------------------------

Greetings,

Jacob

PS: I like a name like "go Ada" better than "something-CPAN".
-- 
Those who can't laugh at themselves leave the job to others.