Re: [AD] set_config_file jumping around on OS X bundles

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sun, 2005-08-21 at 21:30 +0200, Grzegorz Adam Hankiewicz wrote:
> But then you disallow having configuration settings in a .cfg file
> which is not named allegro.cfg. At worst, you will have two .cfg
> files if the programmer is not careful, and depending which are on
> which file allegro_init may ignore something set by a confused user
> on a different configuration file.
> 
> Let's say I have a game called PUCKMAN, and my Windows binary
> is packman.exe.  So I do:
> 
>   set_uformat(U_UNICODE);
>   set_config_file("puckman.cfg");
>   allegro_init();
> 
> And now Allegro will read the configuration from packman.cfg,

Yes, it makes a lot of sense.. but my impression was, it doesn't work.

> rather than having both allegro.cfg and puckman.cfg in the same
> directory. And if I distribute setup/setup.exe I'll tell it to save
> the settings into puckman.cfg. All with the purpose of customising
> the game as much as possible.
> 
> In fact, you could distribute several Allegro binaries in the same
> directory and they should not need to pollute the same allegro.cfg,
> and under Linux you would like to have this feature because otherwise
> all games would use "allegro.cfg" and each would try to overwrite
> settings created by another game (see recent thread pointing this
> problem with language.dat, which is pretty much the same, and whose
> solution is "well, put everything together in a separate directory
> and look in another direction).
> 
> Finally, the "special" code was for those games where somebody
> just copied a binary to somewhere else and the game code
> calls set_config_file but the file is not there and an IO
> error happens. That doesn't have anything to do at all with the
> problem Matthew reported (or at least I look at it on a different
> level). See:
> 
>   http://sourceforge.net/mailarchive/forum.php?thread_id=5254813&forum_id=34598
> 
> cvs annotate is your friend.

Ah, ok. Disregard what I said about linux then.

> > This would hopefully also solve the OSX problem.
> 
> The OSX is completely unrelated and it just calls for a design
> decission. First of all, is the configuration for a game meant to be
> stored inside a bundle? I would say yes, but unfortunatelly Allegro
> doesn't understand several config files at the same time, like a read
> only one inside the bundle and a user specific in the user's home.
> 
> So I would solve the problem by disallowing all configuration
> routines work with files inside the application bundle, and use
> "~/..." as prefix. After all, if an administrator installs a game
> in the Applications folder, should a plain user be able to modify
> files inside the Applications resource folder, potentially afecting
> all users on the system?
> 
> We shouldn't be trigger happy with solving problems, how ever much
> that may hurt releasing 4.2.0. I believe there is another problem
> with get_executable_name under OSX, with returning the path to
> the binary inside the bundle or the bundle directory. Again, this
> is a design decission, which didn't rise before because certainly
> bundles are something new to Allegro.
> 
> Just like how "#" could mean "read inside bundle structure" under
> OSX instead of "read inside datafile appended to binary"... to
> make it more cross-platform... Too many decissions, and not enough
> experienced coders for OSX, it seems.

Does override_config_file work under OSX? Under linux, it is best to
never call set_config_file (since the /etc/allegro.cfg may have vital
driver information for Allegro to start up at all). So I prefer to just
use override_config_file on a game specific file, so settings are first
read from /etc/allegro.cfg, then from the game.cfg, and always written
into the game.cfg.. of course there's still no way to have user specific
settings (that would need a third level).

-- 
Elias Pschernig