From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal 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!feeder.eternal-september.org!aioe.org!.POSTED.2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: How to supply O/S linker arguments with gprbuild? Date: Mon, 22 Jun 2020 22:07:43 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <3f234cce-c49f-40a4-83a4-f0c9860d8abfo@googlegroups.com> <98843f83-9907-4bd4-9600-4bc67e41f883o@googlegroups.com> NNTP-Posting-Host: 2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader01.eternal-september.org comp.lang.ada:59165 List-Id: On 22/06/2020 19:52, Warren wrote: > The above might be useful for some projects, but I didn't want to define a package for each and every library I link with. Actually this is the way. I have 20+ alien libraries from GTK: atk, glib, gobject etc, all of them have a separate project file. The linker switches you use are the end-of-the-chain parameters. They are ignored everywhere else, but when you build an executable. E.g. if you build a library and specify some linker switches for it, you will be warned that they are ignored. Thus you have to copy-paste the package linker from one project to another once you have more than one. It is not scalable and barely maintainable. For this case people usually define empty parent projects with switches or strings set there and pull them into the executable projects combining the linker switches from various sources. It is not nice. The library parameters for the linker that are indeed transferred from the library project to the executable project are specified rather using: Library_Options (and similar attributes) not per switches. See https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html#building-libraries The solution based on Library_Options is almost as good as separate third-party library projects if all your third-party dependencies are always come through your libraries. Yet there is still a chance to have conflicting definitions along different paths from different libraries. E.g. if you have dependencies like (tree) A C \ / B | D You are OK with Library_Options. But if you have this (ADG) A / \ B C \ / D there is a chance that B and C could have conflicting definitions regarding A. If each library has a project you will never have conflicts and there always be only one place to change library options, the library project. > I have a simple Makefile that drives this project, and I simply wanted a central place to configure the pathnames. Another idea to consider would be to ditch makefiles. gprbuild does everything makefiles do and better and more. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de