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!newsfeed1.swip.net!137.226.231.214.MISMATCH!newsfeed.fsmpi.rwth-aachen.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: Jacob Sparre Andersen Newsgroups: comp.lang.ada Subject: Re: CPAN style Ada repository Date: Thu, 12 Dec 2013 09:23:05 +0100 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: <87iouubhqu.fsf@adaheads.sparre-andersen.dk> References: <52976431$1@news.actrix.co.nz> NNTP-Posting-Host: 212.27.3.84.mobile.3.dk Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: loke.gir.dk 1386837682 21302 212.27.3.84 (12 Dec 2013 08:41:22 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 12 Dec 2013 08:41:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Cancel-Lock: sha1:ECFI1BhvnKDQEPNBiV06rDFL/SE= Xref: news.eternal-september.org comp.lang.ada:17986 Date: 2013-12-12T09:23:05+01:00 List-Id: banjo 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 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.