A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/companion_tools.html below:

Website Navigation


4. GPRbuild Companion Tools — GPR Tools User's Guide 26.0w documentation

This chapter describes the various tools that can be used in conjunction with GPRbuild.

4.1. Configuring with GPRconfig 4.1.1. Configuration

GPRbuild requires one configuration file describing the languages and toolchains to be used, and project files describing the characteristics of the user project. Typically the configuration file can be created automatically by GPRbuild based on the languages defined in your projects and the compilers on your path. In more involved situations — such as cross compilation, or environments with several compilers for the same language — you may need to control more precisely the generation of the desired configuration of toolsets. A tool, GPRconfig, described in this section, offers this capability. In this chapter most of the examples can use auto-configuration.

GPRbuild will start its build process by trying to locate a configuration file, using the following rules.

GPRbuild assumes that there are known compilers on your path for each of the necessary languages. A user can manually generate a configuration file (and reference it using --config switch); this is especially useful when:

GPRconfig provides several ways of generating configuration files. By default, a simple interactive mode lists all the known compilers for all known languages. You can then select a compiler for each of the languages; once a compiler has been selected, only compatible compilers for other languages are proposed. Here are a few examples of GPRconfig invocation:

4.1.2. Using GPRconfig 4.1.2.1. Description

The GPRconfig tool helps you generate the configuration files for GPRbuild. It automatically detects the available compilers on your system and, after you have selected the one needed for your application, it generates the proper configuration file.

Note

In general, you will not launch GPRconfig explicitly. Instead, it is used implicitly by GPRbuild through the use of --config and --autoconf switches.

4.1.2.2. Command line arguments

GPRconfig supports the following command line switches:

--target=platform

This switch indicates the target computer on which your application will be run. It is mostly useful for cross configurations. Examples include ppc-elf, ppc-vx6-windows. It can also be used in native configurations and is useful when the same machine can run different kind of compilers such as mingw32 and cygwin on Windows or x86-32 and x86-64 on GNU Linux. Since different compilers will often return a different name for those targets, GPRconfig has an extensive knowledge of which targets are compatible, and will for example accept x86-linux as an alias for i686-pc-linux-gnu. The default target is the machine on which GPRconfig is run.

If you enter the special target all, then all compilers found on the PATH will be displayed.

--show-targets

As mentioned above, GPRconfig knows which targets are compatible. You can use this switch to find the list of targets that are compatible with –target.

--config=language[,version[,runtime[,path[,name]]]]

The intent of this switch is to pre-select one or more compilers directly from the command line. This switch takes several optional arguments, which you can omit simply by passing the empty string. When omitted, the arguments will be computed automatically by GPRconfig.

In general, only language needs to be specified, and the first compiler on the PATH that can compile this language will be selected. As an example, for a multi-language application programmed in C and Ada, the command line would be:

path is the directory that contains the compiler executable, for instance /usr/bin (and not the installation prefix /usr).

name should be one of the compiler names defined in the GPRconfig knowledge base. The list of supported names includes GNAT, GCC and so on. This name is generally not needed, but can be used to distinguish among several compilers that could match the other arguments of --config.

Another possible more frequent use of name is to specify the base name of an executable. For instance, if you prefer to use the Diab C compiler (executable is called dcc) instead of gcc, even if the latter appears first in the path, you could specify dcc as the name parameter.

gprconfig --config Ada,,,/usr/bin       # automatic parameters
gprconfig --config C,,,/usr/bin,GCC     # automatic version
gprconfig --config C,,,/usr/bin,gcc     # same as above, with exec name

This switch is also the only possibility to include in your project some languages that are not associated with a compiler. This is sometimes useful especially when you are using an IDE that supports project files. For instance, if you select “Project file” as a language, the files matching the .gpr extension will be shown in the editor, although they of course play no role for gprbuild itself.

--batch

If this switch is specified, GPRconfig automatically selects the first compiler matching each of the --config switches, and generates the configuration file immediately. It will not display an interactive menu.

-o file

This specifies the name of the configuration file that will be generated. If this switch is not specified, a default file is generated in the installation directory of GPRbuild (assuming you have write access to that directory), so that it is automatically picked up by GPRbuild later on. If you select a different output file, you will need to specify it to GPRbuild.

--db directory, --db-

Indicates another directory that should be parsed for GPRconfig’s knowledge base. Most of the time this is only useful if you are creating your own XML description files locally. Additional directories are always processed after the default knowledge base. The second version of the switch prevents GPRconfig from reading its default knowledge base.

-h

Generates a brief help message listing all GPRconfig switches and the default value for their arguments. This includes the location of the knowledge base, the default target, etc.

4.1.2.3. Interactive use

When you launch GPRconfig, it first searches for all compilers it can find on your PATH, that match the target specified by --target. It is recommended, although not required, that you place the compilers that you expect to use for your application in your PATH before you launch gprconfig, since that simplifies the setup.

GPRconfig then displays the list of all the compilers it has found, along with the language they can compile, the run-time they use (when applicable), and so on. It then waits for you to select one of the compilers. This list is sorted by language, then by order in the PATH environment variable (so that compilers that you are more likely to use appear first), then by run-time names and finally by version of the compiler. Thus the first compiler for any language is most likely the one you want to use.

You make a selection by entering the letter that appears on the line for each compiler (be aware that this letter is case sensitive). If the compiler was already selected, it is deselected.

A filtered list of compilers is then displayed: only compilers that target the same platform as the selected compiler are now shown. GPRconfig then checks whether it is possible to link sources compiled with the selected compiler and each of the remaining compilers; when linking is not possible, the compiler is not displayed. Likewise, all compilers for the same language are hidden, so that you can only select one compiler per language.

As an example, if you need to compile your application with several C compilers, you should create another language, for instance called C2, for that purpose. That will give you the flexibility to indicate in the project files which compiler should be used for which sources.

The goal of this filtering is to make it more obvious whether you have a good chance of being able to link. There is however no guarantee that GPRconfig will know for certain how to link any combination of the remaining compilers.

You can select as many compilers as are needed by your application. Once you have finished selecting the compilers, select s, and GPRconfig will generate the configuration file.

4.1.3. The GPRconfig knowledge base

Note

The role and format of the knowledge base are irrelevant for most users of GPRconfig, and are only needed when you need to add support for new compilers or tweak support for existing ones. You can skip this section if you only want to learn how to use GPRconfig.

All knowledge of compilers is recorded in a set of XML files called the knowledge base. GPRconfig itself has no hard-coded knowledge of compilers, although it does contain a default instance of the knowledge base, which users can override or complement using the switches --db-/--db {dir} described above.

The knowledge base contains various kinds of information:

The end of this section will describe in more detail the format of this knowledge base, so that you can add your own information and have GPRconfig advantage of it.

4.1.3.1. General file format

The knowledge base is implemented as a set of XML files. None of these files has a special name, nor a special role. Instead, the user can freely create new files, and put them in the knowledge base directory, to contribute new knowledge.

The location of the knowledge base is $prefix/share/gprconfig, where $prefix is the directory in which GPRconfig was installed. Any file with extension .xml in this directory will be parsed automatically by GPRconfig at startup after sorting them alphabetically.

All files must have the following format:

<?xml version="1.0" ?>
<gprconfig>
   ...
</gprconfig>

The root tag must be <gprconfig>.

The remaining sections in this chapter will list the valid XML tags that can be used to replace the ‘…’ code above. These tags can either all be placed in a single XML file, or split across several files.

4.1.3.2. Compiler description

One of the XML tags that can be specified as a child of <gprconfig> is <compiler_description>. This node and its children describe one of the compilers known to GPRconfig. The tool uses them when it initially looks for all compilers known on the user’s PATH environment variable.

This is optional information, but simplifies the use of GPRconfig, since the user is then able to omit some parameters from the --config command line argument, and have them automatically computed.

The <compiler_description> node doesn’t accept any XML attribute. However, it accepts a number of child tags that explain how to query the various attributes of the compiler. The child tags are evaluated (if necessary) in the same order as they are documented below.

4.1.3.3. GPRconfig external values

A number of the XML nodes described above can contain one or more children, and specify how to query a value from an executable. Here is the list of valid contents for these nodes. The <directory> and <external> children can be repeated multiple times, and the <filter> and <must_match> nodes will be applied to each of these. The final value of the external value is the concatenation of the computation for each of the <directory> and <external> nodes.

4.1.3.4. GPRconfig variable substitution

The various compiler attributes defined above are made available as variables in the rest of the XML files. Each of these variables can be used in the value of the various nodes (for instance in <directory>), and in the configurations (Configuration).

A variable is referenced by ${name} where name is either a user variable or a predefined variable. An alternate reference is $name where name is a sequence of alpha numeric characters or underscores. Finally $$ is replaced by a simple $.

User variables are defined by <variable> nodes and may override predefined variables. To avoid a possible override use lower case names.

The variables are used in two contexts: either in a <compiler_description> node, in which case the variable refers to the compiler we are describing, or within a <configuration> node. In the latter case, and since there might be several compilers selected, you need to further specify the variable by adding in parenthesis the language of the compiler you are interested in.

For instance, the following is invalid:

<configuration>
<compilers>
<compiler name="GNAT" />
</compilers>
<targets negate="true">
<target name="^powerpc-elf$"/>
</targets>
<config>
package Compiler is
  for Driver ("Ada") use "${PATH}gcc";   --  Invalid !
end Compiler;
</config>
</configuration>

The trouble with the above is that if you are using multiple languages like C and Ada, both compilers will match the “negate” part, and therefore there is an ambiguity for the value of ${PATH}. To prevent such issues, you need to use the following syntax instead when inside a <configuration> node:

for Driver ("Ada") use "${PATH(ada)}gcc";   --  Correct

Predefined variables are always in upper case. Here is the list of predefined variables

If a variable is not defined, an error message is issued and the variable is substituted by an empty string.

4.1.3.5. Fallback targets

When no compiler matches the requirements for a given target, a compiler supporting other targets can be used. These targets are described with the XML tag <fallback_targets> and its <target> children. <fallback_targets> must be a child of the root tag <gprconfig>. All targets contained in the same <fallback_targets> are fallbacks for each other.

<fallback_targets>
    <target>x86-linux</target>
    <target>x86_64-linux</target>
</fallback_targets>

Let’s take an example. If we have the following configuration in a file named config.xml, a call to gprconfig --db config.xml --batch --target=target-0 --config=Ada --fallback-targets will produce a configuration file for a compiler supporting the x86_64-linux target as the target-0 one is not supported by any compiler.

<?xml version="1.0"?>
<!DOCTYPE gprconfig []>

<gprconfig>
    <fallback_targets>
        <target>target-0</target>
        <target>x86_64-linux</target>
    </fallback_targets>
</gprconfig>
4.1.3.6. Configurations

The second type of information stored in the knowledge base are the chunks of gprbuild configuration files.

Each of these chunks is also placed in an XML node that provides optional filters. If all the filters match, then the chunk will be merged with other similar chunks and placed in the final configuration file that is generated by GPRconfig.

For instance, it is possible to indicate that a chunk should only be included if the GNAT compiler with the soft-float runtime is used. Such a chunk can for instance be used to ensure that Ada sources are always compiled with the -msoft-float command line switch.

GPRconfig does not perform sophisticated merging of chunks. It simply groups packages together. For example, if the two chunks are:

chunk1:
   package Language_Processing is
     for Attr1 use ("foo");
   end Language_Processing;
chunk2:
   package Language_Processing is
     for Attr1 use ("bar");
   end Language_Processing;

Then the final configuration file will look like:

package Language_Processing is
  for Attr1 use ("foo");
  for Attr1 use ("bar");
end Language_Processing;

As a result, to avoid conflicts, it is recommended that the chunks be written so that they easily collaborate together. For instance, to obtain something equivalent to

package Language_Processing is
  for Attr1 use ("foo", "bar");
end Language_Processing;

the two chunks above should be written as:

chunk1:
  package Language_Processing is
    for Attr1 use Language_Processing'Attr1 & ("foo");
  end Language_Processing;
chunk2:
  package Language_Processing is
    for Attr1 use Language_Processing'Attr1 & ("bar");
  end Language_Processing;

The chunks are described in a <configuration> XML node. The most important child of such a node is <config>, which contains the chunk itself. For instance, you would write:

<configuration>
  ...  list of filters, see below
  <config>
  package Language_Processing is
     for Attr1 use Language_Processing'Attr1 & ("foo");
  end Language_Processing;
  </config>
</configuration>

If <config> is an empty node (i.e., <config/> or <config></config> was used), then the combination of selected compilers will be reported as invalid, in the sense that code compiled with these compilers cannot be linked together. As a result, GPRconfig will not create the configuration file.

The special variables (GPRconfig variable substitution) are also substituted in the chunk. That allows you to compute some attributes of the compiler (its path, the runtime,…), and use them when generating the chunks.

The filters themselves are of course defined through XML tags, and can be any of:

In addition to the configuration fragments computed by evaluating the main knowledge base, the root directory of the detected runtime is searched for additional XML files and those are added to configuration to provide the runtime-specific customization (the convention is to have a single extra file called runtime.xml, although this is not enforced). These XML files are only expected to contain <configuration><config> XML node and should additionally contain CDATA reference to ensure the additional configuration is properly integrated. For example, a soft-float runtime may add this:

<?xml version="1.0" ?>

<gprconfig>
  <configuration>
    <config><![CDATA[
   package Compiler is
      for Leading_Required_Switches ("Ada") use
         Compiler'Leading_Required_Switches ("Ada") & ("-msoft-float");
   end Compiler;
]]>
   </config>
  </configuration>
</gprconfig>
4.2. Configuration File Reference

A text file using the project file syntax. It defines languages and their characteristics as well as toolchains for those languages and their characteristics.

GPRbuild needs to have a configuration file to know the different characteristics of the toolchains that can be used to compile sources and build libraries and executables.

A configuration file is a special kind of project file: it uses the same syntax as a standard project file. Attributes in the configuration file define the configuration. Some of these attributes have a special meaning in the configuration.

The default name of the configuration file, when not specified to GPRbuild by switches --config= or --autoconf= is default.cgpr. Although the name of the configuration file can be any valid file name, it is recommended that its suffix be .cgpr (for Configuration GNAT Project), so that it cannot be confused with a standard project file which has the suffix .gpr.

When default.cgpr cannot be found in the configuration project path, GPRbuild invokes GPRconfig to create a configuration file.

In the following description of the attributes, when an attribute is an indexed attribute and its index is a language name, for example Spec_Suffix (<language>), then the name of the language is case-insensitive. For example, both “C” and “c” are allowed.

Any attribute may appear in a configuration project file. All attributes in a configuration project file are inherited by each user project file in the project tree. However, usually only the attributes listed below make sense in the configuration project file.

4.2.1. Project Level Configuration Attributes 4.2.1.1. General Attributes 4.2.2. Package Naming

Attributes in package Naming of a configuration file specify defaults. These attributes may be used in user project files to replace these defaults.

The following attributes usually appear in package Naming of a configuration file:

4.2.3. Package Builder 4.2.4. Package Compiler 4.2.4.1. General Compilation Attributes 4.2.5. Package Binder 4.2.6. Package Linker 4.3. Cleaning up with GPRclean

The GPRclean tool removes the files created by GPRbuild. At a minimum, to invoke GPRclean you must specify a main project file in a command such as gprclean proj.gpr or gprclean -P proj.gpr.

Examples of invocation of GPRclean:

gprclean -r prj1.gpr
gprclean -c -P prj2.gpr
4.3.1. Switches for GPRclean

The switches for GPRclean are:

4.4. Installing with GPRinstall

The GPRinstall tool installs projects. With GPRinstall it is not needed to create complex makefiles to install the components. This also removes the need for OS specific commands (like cp, mkdir on UNIXs) and so makes the installation process easier on all supported platforms.

After building a project it is often necessary to install the project to make it accessible to other projects. GPRinstall installs only what is necessary and nothing more. That is, for a library project the library itself is installed with the corresponding ALI files for Ada sources, but the object code is not installed as it not needed. Also if the Ada specs are installed the bodies are not, because they are not needed in most cases. The cases where the bodies are required (if the spec has inline routines or is a generic) are properly detected by GPRinstall.

Furthermore, we can note that GPRinstall handles the preprocessed sources. So it installs the correct variant of the source after resolving the preprocessing directives.

The parts of a project that can be installed are:

Moreover, GPRinstall will create, when needed, a project to use the installed sources, objects or library. By default, this project file is installed in the GPRbuild’s default path location so that it can be “with”ed easily without further configuration. The installation process keeps record of every file installed for easy and safe removal.

GPRinstall supports all kinds of project:

Projects that won’t be installed are:

At a minimum, to invoke GPRinstall you must specify a main project file in a command such as gprinstall proj.gpr or gprinstall -P proj.gpr (in installing mode) or the install name (in uninstalling mode) gprinstall --uninstall proj.

Examples of invocation of GPRinstall:

gprinstall prj1.gpr
gprinstall -r --prefix=/my/root/install -P prj2.gpr

GPRinstall will record the installation under the install name which is by default the name of the project without the extension. That is above the project install names are prj1 and prj2.

The installation name can be specified with the option --install-name. This makes it possible to record the installation of multiple projects under the same name. This is handy if an application comes with a library and a set of tools built with multiple projects. In this case we may want to record the installation under the same name. The install name is also used as a suffix to group include and library directories.

Examples of installation under the same name:

gprinstall --install-name=myapp lib.gpr
gprinstall --install-name=myapp --mode=usage tools/tools.gpr

Note the --mode=usage option above. This tells GPRinstall to only install the executable or the shared library built as part of the project.

It is possible to uninstall a project by using the --uninstall option. In this case we just pass the install name to GPRinstall:

gprinstall --uninstall prj1
gprinstall --uninstall prj2

And both lib.gpr and tools.gpr above will be uninstalled with:

gprinstall --uninstall myapp

Note that GPRinstall does not deal with dependencies between projects. Also GPRinstall in uninstall mode does not need nor use information in the installed project. This is because the project may not be present anymore and many different project scenario may have been installed. So when uninstalling GPRinstall just use the manifest file (whose name is the install name) information.

4.4.1. Switches for GPRinstall

The switches for GPRinstall are:

4.5. Specifying a Naming Scheme with GPRname

When the Ada source file names do not follow a regular naming scheme, the mapping of Ada units to source file names must be indicated in package Naming with attributes Spec and Body.

To help maintain the correspondence between compilation unit names and source file names within the compiler, the tool gprname may be used to generate automatically these attributes.

4.5.1. Running gprname

The usual form of the gprname command is:

$ gprname [`switches`] `naming_pattern` [`naming_patterns`]
    [--and [`switches`] `naming_pattern` [`naming_patterns`]]

Most of the arguments are optional: switch -P must be specified to indicate the project file and at least one Naming Pattern.

gprname will attempt to find all the compilation units in files that follow at least one of the naming patterns. To find Ada compilation units, gprname will use the GNAT compiler in syntax-check-only mode on all regular files.

One or several Naming Patterns may be given as arguments to gprname. Each Naming Pattern is enclosed between double quotes (or single quotes on Windows). A Naming Pattern is a regular expression similar to the wildcard patterns used in file names by the Unix shells or the DOS prompt.

gprname may be called with several sections of directories/patterns. Sections are separated by switch –and. In each section, there must be at least one pattern. If no directory is specified in a section, the project directory is implied. The options other that the directory switches and the patterns apply globally even if they are in different sections.

Examples of Naming Patterns are:

"*.[12].ada"
"*.ad[sb]*"
"body_*"    "spec_*"

For a more complete description of the syntax of Naming Patterns, see the second kind of regular expressions described in g-regexp.ads (the ‘Glob’ regular expressions).

4.5.2. Switches for GPRname

Switches for gprname must precede any specified Naming Pattern.

You may specify any of the following switches to gprname:

4.5.3. Example of gprname Usage 
$ gprname -P/home/me/proj.gpr -x "*_nt_body.ada"
-dsources -dsources/plus -Dcommon_dirs.txt "body_*" "spec_*"

Note that several switches -d may be used, even in conjunction with one or several switches -D. Several Naming Patterns and one excluded pattern are used in this example.

4.6. The Library Browser GPRls

gprls is a tool that outputs information about compiled sources. It gives the relationship between objects, unit names and source files. It can also be used to check source dependencies as well as various characteristics.

4.6.1. Running gprls

The gprls command has the form

$ gprls switches `object_or_dependency_files`

The main argument is the list of object files or ali files for Ada sources for which information is requested.

gprls uses a project file, either specified through a single switch -P, or the default project file. If no object_or_dependency_files is specified then all the object files corresponding to the sources of the project are deemed to be specified. If object_or_dependency_files is specified for an aggregate project and there is more than one such file in different aggregated projects then the file found first is used to show the information.

In normal mode, without option other that -P <project file>, gprls produces information for each object/dependency file: the full path of the object, the name of the principal unit in this object if the source is in Ada, the status of the source and the full path of the source.

Here is a simple example of use:

$ gprls -P prj.gpr
/my_path/obj/pkg.o
   pkg
     DIF pkg.adb
/my_path/obj/main.o
   main
     MOK main.adb

The first three lines can be interpreted as follows: the main unit which is contained in object file pkg.o is pkg, whose main source is in pkg.adb. Furthermore, the version of the source used for the compilation of pkg has been modified (DIF). Each source file has a status qualifier which can be:

OK (unchanged)

The version of the source file used for the compilation of the specified unit corresponds exactly to the actual source file.

MOK (slightly modified)

The version of the source file used for the compilation of the specified unit differs from the actual source file but not enough to require recompilation. If you use gprbuild with the qualifier -m (minimal recompilation), a file marked MOK will not be recompiled.

DIF (modified)

The source used to build this object has been modified and need to be recompiled.

??? (dependency file not found)

The object/dependency file cannot be found.

4.6.2. Switches for GPRls

gprls recognizes the following switches:

--version

Display Copyright and version, then exit disregarding all other options.

--help

If –version was not used, display usage, then exit disregarding all other options.

--closure

Display the Ada closures of the mains specified on the command line or in attribute Main of the main project. The absolute paths of the units in the closures are listed, but no status is checked. If all the ALI files are found, then the list is preceded with the line “Closure:” or “Closures:”. Otherwise, it is preceded with the line “Incomplete Closure:” or “Incomplete closures:”.

-P <project file>

Use this project file. This switch may only be specified once.

-a

Consider all units, including those of the predefined Ada library. Especially useful with -d.

-d

List sources from which specified units depend on.

-h

Output the list of options.

-o

Only output information about object files.

-s

Only output information about source files.

-u

Only output information about compilation units.

-U

If no object/dependency file is specified, list information for the sources of all the projects in the project tree.

-files=file

Take as arguments the files listed in text file file. Text file file may contain empty lines that are ignored. Each nonempty line should contain the name of an existing object/dependency file. Several such switches may be specified simultaneously.

-aPdir

Add dir at the beginning of the project search dir.

--RTS=rts-path

Specifies the default location of the Ada runtime library. Same meaning as the equivalent gprbuild switch.

-v

Verbose mode. Output the complete source, object and project paths. For each Ada source, include special characteristics such as:

4.6.3. Examples of gprls Usage 
$ gprls -v -P prj.gpr

 5 lines: No errors
gprconfig --batch -o /my_path/obj/auto.cgpr --target=x86_64-linux --config=ada,,
Creating configuration file: /my_path/obj/auto.cgpr
Checking configuration /my_path/obj/auto.cgpr

GPRLS Pro 17.0 (20161010) (x86_64-unknown-linux-gnu)
Copyright (C) 2015-2023, AdaCore

Source Search Path:
   <Current directory>
   /my_path/local/lib/gcc/x86_64-pc-linux-gnu/4.9.4//adainclude/

Object Search Path:
   <Current directory>
   /my_path/local/lib/gcc/x86_64-pc-linux-gnu/4.9.4//adalib/

Project Search Path:
   <Current_Directory>
   /my_path/local/x86_64-unknown-linux-gnu/lib/gnat
   /my_path/local/x86_64-unknown-linux-gnu/share/gpr
   /my_path/local/share/gpr
   /my_path/local/lib/gnat

/my_path/obj/pkg.o
   Unit =>
     Name   => pkg
     Kind   => package body
     Flags  => No_Elab_Code
   Source => pkg.adb unchanged
   Unit =>
     Name   => pkg
     Kind   => package spec
     Flags  => No_Elab_Code
   Source => pkg.ads unchanged
/my_path/obj/main.o
   Unit =>
     Name   => main
     Kind   => subprogram body
     Flags  => No_Elab_Code
   Source => main.adb slightly modified

$ gprls -d -P prj.gpr main.o
/my_path/obj/main.o
   main
       MOK main.adb

        OK pkg.ads

$ gprls -s -P prj.gpr main.o
   main
main.adb
4.7. Viewing the Project’s Properties with GPRinspect

The tool gprinspect can be used to display the various properties of a project or a project hierarchy, such as the values of attributes, variables, and so on, in human-readable or JSON format. The tool also displays recommendations on how the project can be refactored to follow best practices.

4.7.1. Running gprinspect

The usual form of the gprinspect command is:

$ gprinspect `project switches` `display switches`

All arguments are optional.

4.7.2. Switches for GPRinspect

GPRinspect recognizes all common project switches, such as -P, -X, --target, and so on. Additionally, the following switches are recognized:

4.7.3. Example of gprinspect Usage

The following command displays all project attributes, including those defined in a current configuration project (i.e. specific to the currently selected toolchain), in JSON format:

$ gprinspect -Pshare/examples/gprbuild/first_steps/ada_main -c --attributes --display=json
...
"projects": [
  {
    "attributes": [
...
      {
        "kind": "list",
        "name": "Source_Files",
        "values": [
          "ada_main.adb",
          "c_lib.ads",
          "lib.h",
          "lib.c"
        ]
      },
...
      {
        "kind": "single",
        "name": "Target",
        "value": "x86_64-linux"
      },
      {
        "index": "Ada",
        "kind": "single",
        "name": "Toolchain_Version",
        "value": "GNAT 25.0"
      }
    ],
...

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4