gnat Project files
rasikasr...@gmail.com
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?
thanks, srini
Dmitry A. Kazakov
> 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.
Yes, I have the same problem too. So far the best solution I know is:
with "common.gpr";
project Dependent is
for Object_Dir use Common'Object_Dir;
...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
AdaMagica
>
> with "common.gpr";
> project Dependent is
> for Object_Dir use Common'Object_Dir;
This is not the best solution, it's *the* solution AdaCore has in mind.
Hibou57 (Yannick Duchêne)
Currently, I do not use GPS, nor the GNAT project facilities, but
still have a question : is it possible to use a relative path for this
common path ? I mean, a relative path which would be interpreted
relatively to another path specific to each project.
AdaMagica
wrote:
> Currently, I do not use GPS, nor the GNAT project facilities, but
> still have a question : is it possible to use a relative path for this
> common path ? I mean, a relative path which would be interpreted
> relatively to another path specific to each project.
You can specify an abolute or releative path, or you can use an
environment variable for project file paths.
with "../Relative_Path/common";
with "/Absolute_Path/something";
project Dependent is ...
Dmitry A. Kazakov
Sure. For example:
� for Object_Dir use "../../" & Common'Object_Dir;
P.S. '/' works under Windows as if it were '\'. Also you should better use
all quoted file names in lower case to make it working under both Linux and
Windows.
Hibou57 (Yannick Duchêne)
On 4 nov, 15:50, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> P.S. '/' works under Windows as if it were '\'. Also you should better use
> all quoted file names in lower case to make it working under both Linux and
> Windows.
If I may add something about general path format : on Windows, spaces
must be avoided in paths, otherwise the debugger will not work (I do
not really use it as well, but I've tried it in a near past). Note :
the GNAT compiler (on Windows) does not requires this, just the
debugger do.
Robert A Duff
> You can specify an abolute or releative path, or you can use an
> environment variable for project file paths.
>
> with "../Relative_Path/common";
> with "/Absolute_Path/something";
> project Dependent is ...
Relative paths are relative to the directory where the project file is,
not (necessarily) relative to the current directory where you're running
the compiler.
- Bob
Stephen Leake
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