|
|
|
This thread is locked; no one can reply to it.
|
| Changing the directory where allegro.log is written |
|
amarillion
Member #940
January 2001
 |
From what I gather from the allegro source (open_trace_file in debug.c), the allegro log is either saved as "allegro.log" in the current directory, or you can use the ALLEGRO_TRACE environment variable to override the location. Problem is that in a Windows 10 situation, you don't have write access to the current directory if it's under C:\Program Files (x86)\MyGame What I want to do is to put the log in the AppData directory instead. I tried to override ALLEGRO_TRACE like so: ALLEGRO_PATH *localAppData = al_get_standard_path(ALLEGRO_USER_SETTINGS_PATH); ALLEGRO_PATH *logPath = al_clone_path(localAppData); al_set_path_filename(logPath, "allegro.log"); setenv("ALLEGRO_TRACE", al_path_cstr(logPath, ALLEGRO_NATIVE_PATH_SEP), 1); Except that doesn't work. I think because ALLEGRO_TRACE has to be set before allegro_init, and you can't call al_get_standard_path before allegro_init. Does anybody know a solution? By the way, is it possible to add your own log statements to the same log file? That is not documented AFAICT. -- |
|
Elias
Member #358
May 2000
|
I think we should add a config option in addition to the environment variable - but the issue of not being able to use al_get_standard_path would remain. Maybe we should put allegro.log in a writable location by default - the issue is similar in OSX and Linux in fact, the current directory is not necessarily writable. Just during development it usually is. Maybe put it in $TEMP? Or if we add a config option, allow selecting a standard directory, something like: al_set_config_value(al_get_system_config(), "trace", "standard_location", "ALLEGRO_USER_SETTINGS_PATH"); What you can do right now is use al_register_trace_handler then Allegro will call your callback and you can write to whichever file you want (you miss the first few lines of the log before you register the callback, but that should not be too terrible). Writing to the same file from user code does work but I guess is considered use of internal functions - if we change Allegro's logging at some point and you use ALLEGRO_DEBUG in your code, it may break. If you use al_register_trace_handler you can of course call your callback function yourself. -- |
|
amarillion
Member #940
January 2001
|
If you're happy with this design, I could have a go at writing a patch for this. A bit of background: Just finished debugging a troublesome issue, where OGG files weren't loading properly. al_load_sample ("xxx.ogg") would just return NULL with no further indication what was wrong. It turns out that I was missing libvorbisfile.dll, I found out by stepping through the code with gdb. I would have found out more quickly if I had the log file available, but alas. Oddly though, I did try to run the game outside of Program Files (from Documents, in a writable directory), and still the log file didn't appear. There might be something else at play here as well, I don't know. -- |
|
Bruce Pascoe
Member #15,931
April 2015
 |
amarillion said: It turns out that I was missing libvorbisfile.dll Yet another victim of the allegro_acodec dynamic loading.
|
|
amarillion
Member #940
January 2001
|
Yes, it would be better with batteries included! -- |
|
SiegeLord
Member #7,827
October 2006
 |
Elias said: What you can do right now is use al_register_trace_handler then Allegro will call your callback and you can write to whichever file you want (you miss the first few lines of the log before you register the callback, but that should not be too terrible). Looking at the code, it appears safe to call it before al_init(), so we could document that and solve that secondary issue. But anyway, nothing really solves the al_get_standard_path issue. We'd have to re-write a bit of code to get that to work before system init (even if we go with the internal usage proposed by Elias). Maybe Allegro could try a few dirs and then report which one it chose using something like al_get_log_dir()? "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
amarillion
Member #940
January 2001
|
Thinking about this, I think a better solution is to add a function al_set_log_file, and switch the log file to that location from that moment on. Elias' solution won't work because the value of al_get_standard_path() depends not only on al_init(), but also al_set_app_name() and al_set_org_name(). So you really can't know when the standard appdata path has its final value. I think the best solution is an explicit function call such as al_set_log_file -- |
|
|
Guess it really is a good thing we disabled that by default in the latest builds.