This in fact slightly changes the priority order of added archives. Formerly,
all archives in SearchMan were preferred to the customly added ones in
ArchiveMan. All standard paths (i.e. path and extrapath) will be still be
searched before the custom ones (which are all priority 0 right now) but system
specific paths will be searched after (due to their priority being -1). Since
system specific paths shouldn't contain any game data files this should
hopefully be harmless.
This wasn't tested for games with CAB archives.
Each engine now only has to provide a single configure.engine file
adding the engine into the configure script, which then produces the
required other files automatically.
This is the third and final commit enabling fully pluggable engines.
Now providing an engine folder contains a configure.engine, engine.mk
and engine-plugin.h file, it will be picked up automatically by the
configure script.
This is the second part of allowing engines to be added dynamically.
Each folder in engines/ which must contain a file named "engine.mk"
containing the make definitions for that engine.
This is the first part of allowing engines to be added dynamically.
They are placed into a folder in engines/ which must contain a file
named "configure.engine" to add the engine, which is pulled into the
top level configure script automatically.
This allows to keep the engines to specfiy the files for translation close to
the engine sources itself.
Thanks to criezy for his suggestion on this approach.
This shouldn't actually be necessary since, as far as I can tell,
its only purpose is to toggle between true and false to slow down
some mouse cursor animations. But Valgrind doesn't know that.
On some systems, passing signed chars to macros like isspace() etc. lead
to a runtime error. Hence, mark these macros as forbidden by default,
and introduce otherwise equivalent alternatives for them.
Now all of the Archive API is implemented to avoid possibly inconsistent
behavior when an ArchiveMan object is accessed via a class type higher in the
class hierachy.
Formerly the hasFile method was non-const, thus did not overwrite the virtual
hasFile method of SearchSet. Since all accesses to this function have been
done through a ArchiveMan typed variable, the missing overwrite should not
have caused any trouble.
It looks like this was forgotten in a6ec4f70da120a1ce406ed4dd9e149e081542f59.
