Re: How to supply O/S linker arguments with gprbuild?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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