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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,39bde956b245c191 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.56.163 with SMTP id b3mr18037354pbq.0.1323001687557; Sun, 04 Dec 2011 04:28:07 -0800 (PST) Path: lh20ni68257pbb.0!nntp.google.com!news2.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!newsfeed.kamp.net!newsfeed0.kamp.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: How to nicely distribute a simple Ada library? Date: Sun, 04 Dec 2011 13:28:00 +0100 Organization: A noiseless patient Spider Message-ID: <87wraczflb.fsf@ludovic-brenta.org> References: Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="x+UJ+1kI5vuqbZOWHGZmWw"; logging-data="21163"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX187taaCnTTpDTDpq6x8jl6M" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Cancel-Lock: sha1:VREZdYMz4/GCY+S3ZqNeVz4ynDs= sha1:aGLyTZLny9HThtwZGCY/FZCTMa0= Xref: news2.google.com comp.lang.ada:14818 Content-Type: text/plain; charset=us-ascii Date: 2011-12-04T13:28:00+01:00 List-Id: Natasha Kerensikova writes: > sorry for spamming you again, and for the arrogance of thinking anyone > might possibly want to use my code, but I'm wondering what is the best > way to distribute a library (once it's ready for release) written in > Ada. > > I have found the packaging policies for Debian, which is very complete > and useful, and for Fedora, which seems nice too but less interesting > for upstream. And I would like to eventually maintain a FreeBSD port. > > So my first question is, since the policies say to include in the > package all the body and specification files required to compile > something against the library, but not the others, how can I know > which files are required and which are not? When in doubt, include everything that is written in Ada. > The policies also ask for a .gpr file used for building programs > against the library, which seems different from the .gpr file used to > build the library itself. Should I, as upstream, try to provide both > of them, or should I leave the former .gpr file to the packager? It is the packager's responsibility to provide the .gpr file used for building against the library. In particular, the location where GNAT will look for this .gpr file depends on the version of GNAT and on the distribution. So, do not bother creating a .gpr file for a particular distribution unless you are also the packager for that distribution. However, you might want to provide a .gpr file for people who install your library from sources (as opposed to from their distribution's packages). This .gpr file should not assume anything about where it, or other .gpr files, are installed but it may make assumptions about where the library sources, .ali and .so files are installed relative to itself; see below. > I gather that packaging systems have their own way to perform the > installation, but how can I provide an installation mechanism that > does not depend on a distribution? I would rather avoid automess > tools, they feel extremely overkill compared to the simplicity and > presumed portability of my libraries. I can write a `make install` in > pure makefile language, but is there another more idiomatic way of > doing it? People who install from source are used to "./configure; make; sudo make install", so maybe you should provide an empty, no-op configure script and a Makefile. The default destination directory should be /usr/local and there should be a way to override this default at install time (e.g. "sudo make install DESTDIR=$HOME/lib"). The "install" target of your Makefile should respect the Filesystem Hierarchy Standard and place everything in subdirectories of $(DESTDIR). Anything beyond that is overkill IMHO. > What about windows or mac platforms? That's why the job of a packager is not the same as the job of the upstream author :) If you don't have Windows or Mac OS X, leave that job to other people who do have them and are prepared to contribute. > And while all the above assumes a GNAT toolchain, there are probably > people using other compiles. I guess I cannot really support all Ada > compilers that exist (especially those to which I don't have access), > so the burden for porting the library to their toolchain is probably > theirs, but is there any step I should to make it easier for them? I would say: don't bother. If you follow the guidelines below, it should be extremely easy for someone with another Ada compiler to use your library and perhaps even contribute patches back to you. > And lastly, is there anything else I should know to make my libraries > easier to use for packagers and users? To make life easier to everyone: - Do not split your sources into many directories. Ideally a single directory, unless there are several configurations to choose from at build time. - Avoid preprocessing steps (especially automess) - Do not require the use of a Makefile to use the library (requiring one to build the library is OK). - Make the .gpr files as simple as you can; they should be readable by a human not familiar with the .gpr syntax. This makes it easy for people with compilers other than GNAT to build and use your library. HTH -- Ludovic Brenta. Controlling should globally think out of the box.