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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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.16.106 with SMTP id f10mr4639500pbd.8.1323339493270; Thu, 08 Dec 2011 02:18:13 -0800 (PST) Path: lh20ni82738pbb.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: How to nicely distribute a simple Ada library? Date: Thu, 8 Dec 2011 10:18:12 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <4edb8625$0$7623$9b4e6d93@newsspool1.arcor-online.net> Mime-Version: 1.0 Injection-Date: Thu, 8 Dec 2011 10:18:12 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="7fyd7lCvGVUn5eibBXudkw"; logging-data="18272"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18DXEiAZ1PlmiLTheMO1XXV" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:vbC/VmJ/aCZ6+k+/XiCXLHQwnR0= Xref: news1.google.com comp.lang.ada:19384 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2011-12-08T10:18:12+00:00 List-Id: On 2011-12-04, Georg Bauhaus 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