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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,97cf8dc45eee6abf X-Google-Attributes: gid103376,public From: geert@gonzo.sun3.iaf.nl (Geert Bosch) Subject: Re: Help! --Interfacing GNAT 3.05 to C libraries Date: 1997/05/10 Message-ID: <5l1h5o$1s1$1@gonzo.sun3.iaf.nl>#1/1 X-Deja-AN: 240533437 References: <33719153.6BCC@laurel.datsi.fi.upm.es> <5ktc0d$q5c$1@gonzo.sun3.iaf.nl> <337395B6.2BFA@gsfc.nasa.gov> Organization: La Calandre Infortunee Newsgroups: comp.lang.ada Date: 1997-05-10T00:00:00+00:00 List-Id: Geert Bosch wrote: Actually I'd recommend using pragma Linker_Options ("-lFoo"); in the package using the function. This way you don't need to think about all required linker options when using some packages in your program. In this case, when "ada-program" uses some package, which Stephen Leake (Stephen.Leake@gsfc.nasa.gov) replied: Please don't! If you then give this program to me, and I try to use ObjectAda to link it, I have to find and edit the Linker_Options pragma, based on a weird error message from the linker, which WON'T point me to the file containing the Linker_Options pragma. (Actually, I don't know if gnat linker options have the same format as ObjectAda ones, but you get the point). Linker options are outside the language, and belong in a makefile, or some other compilation script. This also documents ALL the components of the system in one place; otherwise, you might forget to give me libFoo.a. Geert replies: It is a bit strange that you make strong claims about weird error messages you will get because of incompatibility of pragma Linker_Options between GNAT and ObjectAda, when at the same time you admit that you don't know about any incompatibilities. In any case I do not agree with your comment that Linker_Options are outside the language. When you look in your Ada RM, you will find in B.1: 37 Pragma Linker_Options has the effect of passing its string argument as a parameter to the system linker (if one exists), if the immediately enclosing compilation unit is included in the partition being linked. The interpretation of the string argument, and the way in which the string arguments from multiple Linker_Options pragmas are combined, is implementation defined. This does not sound as outside the language to me, in contrast to the Makefiles and compilation scripts you suggest as a better solution. Of course the standard cannot precisely describe the effects of pragma Linker_Options (what is a system linker, or passing a parameter to it?), but I think the intent of the paragraph is clear. I would expect all Ada compilation systems to behave the same on a given platform. I do not think using pragma Linker_Option is a problem when moving between platforms. When a package uses an external library or something else for which a Linker_Option is needed, that package is system dependent anyway. When moving to another platform changing Linker_Options might be one of the necessary actions. (It's a good idea to keep them at the "top" of a compilation unit, just like platform dependent named constants.) IMHO makefiles are evil and should be avoided where possible. Fortunately the Ada language makes it possible to use smart make tools like gnatmake that do not require "makefiles" which are complex and hard to maintain because they depend on all program units. Now back to the original problem, namely interfacing to a GUI library. The solution of creating a package that defines the interface to the the library (using pragma Import and Export) and has a pragma Linker_Options to link in the GUI library when the GUI package is withed, is an easy solution that keeps the system-dependent GUI stuff where it belongs: in the GUI package. Regards, Geert