Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add libretro assets directory search path, and have environment variables override configured values #17054

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

Apteryks
Copy link

Description

See the commit messages, but in a nutshell, this adds support to set/override the assets_directory configured via a LIBRETRO_ASSETS_DIRECTORY environment variable. The behavior of the existing LIBRETRO_DIRECTORY environment variable is changed so that it also overrides any libretro_directory value, with the rationale explained in the commit message.

Related Issues

https://issues.guix.gnu.org/38439

Related Pull Requests

used

* frontend/drivers/platform_win32.c (frontend_win32_env_get): Check
the size of correct destination array.
This builds on 763fcd8 ("unix, win32: Allow set the default
libretro_directory via environment variable") to also allow specifying
the assets directory via an environment variable.

* frontend/drivers/platform_unix.c (frontend_unix_get_env)
<libretro_assets_directory> New variable. Use it to set
DEFAULT_DIR_ASSETS, when available.
* frontend/drivers/platform_win32.c (frontend_win32_env_get): Likewise.
Until now, and unlike the defaut core directory, the default
core *info* directory would be hard-coded relative to the installation
directory. Honor the LIBRETRO_DIRECTORY environment variable the same
instead.

* frontend/drivers/platform_unix.c (frontend_unix_get_env): Set
DEFAULT_DIR_CORE_INFO default to the value of the LIBRETRO_DIRECTORY
environment variable, if available.
* frontend/drivers/platform_win32.c (frontend_win32_env_get): Likewise.
@Apteryks Apteryks force-pushed the add-libretro-assets-directory-search-path branch from 08828a2 to f1df3e7 Compare October 2, 2024 00:45
* frontend/drivers/platform_unix.c
(libretro_autoconfig_directory): New variable.
(frontend_unix_get_env): Set DEFAULT_DIR_AUTOCONFIG to the value of
the LIBRETRO_AUTOCONFIG_DIRECTORY environment variable, if available.
* frontend/drivers/platform_win32.c: Likewise.
…ble.

* frontend/drivers/platform_unix.c
(libretro_video_filter_directory): New variable.
(frontend_unix_get_env): Set DEFAULT_DIR_VIDEO_FILTER to the value of
the LIBRETRO_VIDEO_FILTER_DIRECTORY environment variable, if available.
* frontend/drivers/platform_win32.c: Likewise.
…ble.

* frontend/drivers/platform_unix.c
(libretro_video_shader_directory): New variable.
(frontend_unix_get_env): Set DEFAULT_DIR_SHADER to the value of
the LIBRETRO_VIDEO_SHADER_DIRECTORY environment variable, if available.
* frontend/drivers/platform_win32.c: Likewise.
Because the configuration file is systematically written when
RetroArch terminates, persisting any previous default/configured
value, setting the LIBRETRO_DIRECTORY, LIBRETRO_ASSETS_DIRECTORY, etc.
environment variables would not have an effect unless the
retroarch.cfg configuration file was cleared.

This seems to go against the common expectation that environment
variables are set by users to *override* the default behavior or
configuration of an application.

* configuration.c (config_load_file) <libretro_directory>
<libretro_assets_directory, libretro_autoconfig_directory>
<libretro_video_filter_directory, libretro_video_shader_directory> :
New variables. Use the values of the LIBRETRO_DIRECTORY,
LIBRETRO_ASSETS_DIRECTORY,
LIBRETRO_AUTOCONFIG_DIRECTORY, LIBRETRO_VIDEO_FILTER_DIRECTORY
and LIBRETRO_VIDEO_SHADER_DIRECTORY environment variables
instead of their corresponding configured values, when set.
* docs/retroarch.6: Document the environment variables honored and
their behavior.
@Apteryks Apteryks force-pushed the add-libretro-assets-directory-search-path branch from f1df3e7 to b03edd7 Compare October 2, 2024 03:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant