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

Insert XDG_DATA_DIRS into data loading path #6603

Closed
DorpsGek opened this issue Aug 12, 2017 · 3 comments
Closed

Insert XDG_DATA_DIRS into data loading path #6603

DorpsGek opened this issue Aug 12, 2017 · 3 comments
Labels
enhancement Issue would be a good enhancement; we accept Pull Requests! flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) OS: Linux Issues specific to Linux builds stale Stale issues

Comments

@DorpsGek
Copy link
Member

chrysn opened the ticket and wrote:

For openttd to be usable in a relocatable way (in the sense of that the same build can be installed in arbitrary locations), it would be nice if the path described in XDG_DATA_DIRS (as described on 1).

My use case is user installable debian packages, but the mechanism is used by snappy packages just as well, and can benefit flatpak as same build that is used for regular installations can then also be used in flatpak.

I'd provide a patch for that, but the current mechanism with the `enum Searchpath` can not easily be extended to components that are paths by themselves: There can be one SP_SHARED_DIR, but XDG_DATA_DIRS could contain `/home/user/my-packages/share:/usr/share`.

Would it be OK to replace some of the Searchpath mechanism with something that can get multi-path components from the environment? Should I try to make it work with the enum style paths, possibly making NUM_SEARCHPATHS a static int rather than a constant? Do you have better suggestions on how I could approach such a change?

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/6603
@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 7, 2018
@frosch123 frosch123 removed the Core label Apr 14, 2018
@stale
Copy link

stale bot commented Jan 24, 2019

This issue has been automatically marked as stale because it has not had any activity in the last two months.
If you believe the issue is still relevant, please test on the latest nightly and report back.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale Stale issues label Jan 24, 2019
@nielsmh nielsmh added OS: Linux Issues specific to Linux builds and removed stale Stale issues labels Jan 25, 2019
@nielsmh
Copy link
Contributor

nielsmh commented Jan 25, 2019

This is still relevant and would let the game be a better citizen in *nix desktop environments.

@stale
Copy link

stale bot commented Mar 26, 2019

This issue has been automatically marked as stale because it has not had any activity in the last two months.
If you believe the issue is still relevant, please test on the latest nightly and report back.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale Stale issues label Mar 26, 2019
@stale stale bot closed this as completed Apr 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Issue would be a good enhancement; we accept Pull Requests! flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) OS: Linux Issues specific to Linux builds stale Stale issues
Projects
None yet
Development

No branches or pull requests

4 participants