Under Unix you usually have two ways of redistributing your binaries. You
either pack everything in a single directory, even providing Allegro in
binary or source form for the user to compile. Or your program is being
packaged separately from Allegro and stored in different paths. For the
first case of redistribution, read section "Files shared by Allegro" from
the "Dos specifics" chapter to learn more about this.
For the second type, you can ignore redistributing the setup, keyboard
mappings and language datafiles, because they will be already installed in
the system. This, however, is problematic if you are using get_config_text()
to localise your program's text strings.
The problem is that on other platforms you usually mix your program's text
strings with those of Allegro (found in the `resources' directory) to create
a special language.dat. And it is likely that the Allegro library installed
on the user's system already contains a datafile.dat. You can go ahead and
still provide your own language.dat file, but this will mean that if Allegro
is updated, your language.dat file may not contain all the text strings used
by the new version.
Given the slow paced release cycle of Allegro, this might not be a concern.
However, if you want to make it easy on system administrators, instead of
providing your own `language.dat', you should provide the separate
`xxtext.cfg' files it in a separate directory. Then, before showing the
strings to the user you can detect the language setting and use
override_config_file() with the appropriate localisation file and call
In order to locate things like the config and translation files, Allegro
needs to know the path to your executable. Since there is no standard way to
find that, it needs to capture a copy of your argv parameter, and it does
this with some preprocessor macro trickery. Unfortunately it can't quite
pull this off without a little bit of your help, so you will have to write
END_OF_MAIN() right after your main() function. Pretty easy, really, and if
you forget, you'll get a nice linker error about a missing _mangled_main
function to remind you :-)
Under Unix resources are searched for in many different paths (see above).
When a configuration resource is looked for, it is usually tried with the
variations `name.cfg' or `.namerc' in multiple paths: the current directory,
the directory pointed to by the ALLEGRO environment variable, the user's home
directory, one or more global system directories which usually only the
root user has access to and any custom paths set up with
set_allegro_resource_path(). Text files, like the main allegro config file or
a language text translation files are looked for in the following places:
Binary resources like the language translation files packfile (language.dat)
are looked for in:
Note that if you have installed Allegro from the source distribution with
the typical `make install
', global files like `language.dat' and
`allegro.cfg' will not have been installed. As a system administrator you are
required to install them manually wherever you prefer to have them. If you
suspect that an Allegro program is somehow not finding the correct
configuration file, you could try using the following command:
strace program 2>&1|egrep "(open|stat)"
The strace program traces system calls and signals. By default it outputs
the information to stderr, so that's why we redirect it to stdin with `2>&1
Since we are interested only in files being (un)successfully opened, we
restrict the output of the log to stat or open calls with the extended grep
command. You could add another grep to filter only lines with text like
`language' or `allegro'.
- JOY_TYPE_ - Supported Linux joystick drivers.
- GFX_ - Supported Linux console graphic drivers.
- GFX_ - Supported X graphic drivers.
- DIGI_ - Supported Unix digital sound drivers.
- MIDI_ - Supported Unix MIDI sound drivers.
Unix integration routines