Re: How to nicely distribute a simple Ada library?

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2011-12-04, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:
> On 04.12.11 12:19, Natasha Kerensikova wrote:
>
>> 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?
>
> If your library depends on Ada only, then only an Ada compiler
> is required. I find this a sign of quality.

Does it mean I should rather embed a library (especially if it's simple
and from me) than depend on it externally?

I'm thinking about the Natools thing here: it's code that will end up
useful in several projects of mine, so it certainly make sense to fator
it out into project-agnostic Ada packages.

From there I thought in the C/Unix way, and planned to make Natools a
dynamic library. But you seem to think it's the opposite of a quality
approach, have I understood correctly?

I can embed the Natools into the project cleanly (or at least, cleanly
enough for me). I would guess it leads to a negligible amount of extra
disk space used, and the lack of system-wide updates, which is somewhat
uncomfortable (what if I forget about a binary that embeds Natools, and
fail to update it after encountering a security issue or a critical
bug?).

On the other hand, in-place dynamic library update seems even more
fragile in Ada than in C, because it requires .ali compatibility on top
of binary compatibility. So maybe the drop-in compatible replacement is
too rare to be worth considering, isn't it?

Other than that, I'm also writing binding to C libraries, which have the
obvious non-Ada dependency, but that cannot be avoided.

> I'd start from guiding questions:
>
> (0) Is this a source distribution?
>
> (1) Does your library depend on an implementation?
>
> (2) Does your library include test cases?
>
> (3) Does your library need the services of an OS, or OS abstraction?

I have no plan of ever answering "no" to (0). And I think if I ever do,
it will be for a company or a distribution, which will provide me with
their "right" way of doing it anyway, so I don't need to care about it
now.

(1) is an interesting question. I guess the answer is "yes" for my
bindings to C libraries, in that GNAT provides interface for GCC C
libraries. On the other hand, the source itself does not depend (as far
as I know) on GNAT itself, only on an Ada compiler that correctly
interfaces with the relevant C compiler.

(2) should be yes most of the time.

(3) depends which project of mine is being considered. I avoid them when
I can (e.g. when I need a filter from unix standard input to standard
output, I use Ada.Text_IO.Current_Input and ..._Output), but sometimes
Ada standard library is not enough (e.g. for TCP sockets).

> I'll assume the answer to (0) is yes.
>
> As a general guiding principle, it will greatly help portability
> if sources are such that they can be translated separately with
>
>   pragma Restrictions (
>    No_Implementation_Attribute,
>    No_Implementation_Pragmas,
>    No_obsolescent_Features);

It seems I do use a GNAT-specific pragma, which is pragma Unreferenced.
I find it very useful (with the associated "unreferenced" warning), but
only during active development. I guess once released, and used without
modification, it becomes useless?

Should I remove them from the release branch, for better portability?
(Probably "removed" as in "commented out", so that humans reading the
code understand it's intentional.) Or should I leave that to non-GNAT
users (with a warning in the README), since it's such an easy change?

> I'd not add a premature install target before version 2.0 ;-)
> With a source distribution, there is not so much need for one, anyway.

OK, thanks a lot for all your advice (even what I snipped, I still read
and assimilated it).


Natasha