Re: gnat Project files

[Stephen Leake <stephen_leake@stephe-leake.org>]

"RasikaSrinivasan@gmail.com" <rasikasrinivasan@gmail.com> writes:

> I have a "common.gpr" for a number of projects. I was hoping I could
> define Exec_Dir, Object_Dir etc in just in the common.gpr. But it does
> not appear to be inherited in the lower level gprs. Am I missing
> something?

Yes :).

One use of project files is to keep separate sets of sources and build
directories for each project, so higher-level projects can share
lower-level projects.

For example, I have this directory structure:

GDS -- top level
    sal -- math and other utilities
        build
            x86_gnu_windows     -- native Windows
            x86_gnu_lynx_linux  -- cross target Linux to Lynx
            x86_gnu_linux       -- native Linux
        source -- *.ad[sb]

    common -- core GDS stuff
       build
            x86_gnu_windows     -- native Windows
            x86_gnu_lynx_linux  -- cross target Linux to Lynx
            x86_gnu_linux       -- native Linux
        source -- *.ad[sb]

    smm -- music manager
        build
            x86_gnu_windows     -- native Windows

Each x86_* directory has a project file, and local obj subdirectory.
Exec_Dir has the default value of the x86_* directory; that's where
test executables get built.

smm and common both use sal, but they have nothing else in common. The
compiler only has to compile sal once, when compiling smm or common.


You can also set compiler options in a common gpr file, and then use
renames on the compiler package:

project Shared is

    package Compiler is
        for Default_Switches ("Ada") use ("-gnat05");

        -- other switches
    end Compiler;
end Shared;

with "shared";
project Common is

    package Compiler renames Shared.Compiler;

end Common;

-- 
-- Stephe