[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
16.1 Command Line Options 16.2 Environment Variables 16.3 Files 16.4 Reporting Suggestions and Bugs 16.5 Solving Problems
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Usage: gps [options] [-P project-file] [source1] [source2] ... Options: --help Show this help message and exit --version Show the GPS version and exit --debug[=program] Start a debug session and optionally load the program with the given arguments --debugger debugger Specify the debugger's command line --host=tools_host Use tools_host to launch tools (e.g. gdb) --target=TARG:PRO Load program on machine TARG using protocol PRO --load=lang:file Execute an external file written in the language lang --eval=lang:file Execute an in-line script written in the language lang --tracelist Output the current configuration for logs --traceon=name Activate the logs for a given module --traceoff=name Deactivate the logs for a given module --tracefile=file Parse an alternate configuration file for the logs Source files can be absolute or relative pathnames. If you prepend a file name with '=', this file will be searched anywhere on the project's source path |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following environment variables can be set to override some default settings in GPS:
INSTALL
in
the GPS sources for more details) to access information such as the location
of the translation files.
This option is enabled by default when running GPS locally (DISPLAY
set
to ":0.0"
) and disabled otherwise. Setting this variable explicitely
overrides the default behavior.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Note that the name of the log file is configured by the `traces.cfg' file.
File->Save More->Desktop
),
loaded automatically if found.
Run->Custom...
dialog).
sessions
directory represents a particular session
saved by the user.
This file is created automatically when the `$HOME/.gps/' directory is created. If you remove it manually, it won't be recreated the next time you start GPS. When upgrading to a new version of GPS, it is recommended to remove it since its contents may change from version to version.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you would like to make suggestions about GPS, or if you encountered a bug, please report it to mailto:report@gnat.com if you are a supported user, and to mailto:gps-devel@lists.act-europe.fr otherwise.
Please try to include a detailed description of the problem, including sources to reproduce it if possible/needed, and/or a scenario describing the actions performed to reproduce the problem, as well as the tools (e.g debugger, compiler, call graph) involved.
The files `$HOME/.gps/log' and `$HOME/.gps/debugger.log' may also bring some useful information when reporting a bug.
In case GPS generates a bug box, the log file will be kept under a separate name (`$HOME/.gps/log.<pid>' so that it does not get erased by further sessions. Be sure to include the right log file when reporting a bug box.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section addresses some common problems that may arise when using or installing GPS.
A: You should check the permissions of the directory $HOME/.gps and its subdirectories, they should be owned by the user.
Debug->Initialize
), it is usually because the underlying debugger
(gdb) cannot be launched properly. To verify this, try to launch the
'gdb' command from a shell (i.e outside GPS). If gdb cannot be launched from
a shell, it usually means that you are using a wrong version of gdb
(e.g a version of gdb built for Solaris 8, but run on Solaris 2.6).
ps
and kill
, or the top
command under Unix,
and the Task Manager
under Windows: this will terminate your debugging
session, and will unblock GPS.
gnatlink
command (or `-g' is used in the
gnatmake
command itself).
The name of this package containing the main program is `b~xxx.ads/adb' where xxx is the name of the Ada main unit given in the gnatbind command, and you can edit and debug this file in the normal manner. You will see a series of calls to the elaboration routines of the packages, and you can debug these in the usual manner, just as if you were debugging code in your application.
The simplest is to recompile your application by adding the switches
`-a' and `-f' to the gnatmake
command
line. This extra step is then no longer required, assuming that you
keep the generated object and ali files corresponding to the GNAT run time
available.
Another possibility on Unix systems is to use the file `Makefile.adalib' that can be found in the adalib directory of your GNAT installation and specify e.g `-g -O2' for the `CFLAGS' switches.
There are several solutions to handle this issue:
There is one specific case where a project is allowed to have duplicate source files: if the list of source directories is specified explicitly. All duplicate files must be in the same project. With these conditions, there is no ambiguity for GPS and the GNAT tools which file to use, and the first file found on the source path is the one hiding all the others. GPS only shows the first file.
You can then have a scenario variable that changes the order of source directories to give visibility on one of the other duplicate files.
The idea is that you define various scenarios in your project (For instance compiling in "debug" mode or "production" mode), and change the source directories depending on this setup. Such projects can be edited directly from GPS (in the project properties editor, this is the right part of the window, as described in this documentation). On top of the project explorer (left part of the GPS main window), you have a combo box displayed for each of the variable, allowing a simple switch between scenarios depending on what you want to build.
These projects cannot currently be created through GPS, so you will need to edit them by hand. See the GNAT user's guide for more information on extending projects.
The idea behind this approach is that you can have a local overriding of some source files from the common build/source setup (if you are working on a small part of the whole system, you may not want to have a complete copy of the code on your local machine).
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |