Better resources paths - Githubissues

omf2097 / openomf

One Must Fall 2097 Remake

http://www.openomf.org

MIT License

362 stars 35 forks source link

Better resources paths #285

Closed katajakasa closed 3 months ago

katajakasa commented 9 years ago

Instead of using /usr/share/openomf, we should move resources to /usr/share/games/openomf.

We should also use subdirectories, so that distros can linkfarm if they need to. Eg.

/usr/share/games/openomf/resources (For old/original resources)
/usr/share/games/openomf/new (For new resources. Better name ?)
/usr/share/games/openomf/plugins (Maybe ? Or some other place ? These will be dll/so's).

Vagabond commented 9 years ago

I am fine with this, although we should ideally make this configurable, or maintain it as a relative path to the binary, because the Debian way is not the only way.

katajakasa commented 9 years ago

Yeah, let's keep it relative. So "../share/games/openomf/..." etc. We could also add a commandline argument for overriding it I guess, so that distros could make a wrapper shell script if necessary.

animehunter commented 9 years ago

I like the idea of overriding the path on the commandline.

katajakasa commented 9 years ago

So after taking a look at our path management code, I think we don't absolutely need a separate path for new and old resources. It would just be a pile of work and I don't feel like doing it. However, commits/patches welcome, if somebody WANTS to take care of it :D

Vagabond commented 9 years ago

Should we notify the debian people?

Rondom commented 9 years ago

Would you be open to a pull request making the paths configurable during build? The Debian-way is not the only way and wrapper scripts sound a bit overkill for such a simple thing.

Vagabond commented 9 years ago

Yes, please.

katajakasa commented 9 years ago

@Rondom PR's welcome. Btw, I took a look at the debian ITP's. It's probably not a good idea to separately package libshadowdive (please see libShadowDive readme: https://github.com/omf2097/libShadowDive/blob/master/README.md).

Rondom commented 9 years ago

I read the Readme and I have actually created test-packages using both static linking and dynamic linking. Both is possible, but static linking is frowned upon in Debian, so I plan to ask others for feedback.

katajakasa commented 9 years ago

Well, just note then that the library will be broken and API will change pretty much all the time. Afaik that isn't very well received in debian either :P

katajakasa commented 9 years ago

Oh, and. Current debian libdumb package will not work with openomf; it's too old. So you either need to update the debian package or statically link the kode54 library. libxmp may work, but the playback quality isn't as good.

Vagabond commented 9 years ago

Yeah, the only reason we have libsd as a seperate lib is because we also use it for our command line tools. We could just merge everything into one big repo, but we definitely prefer static linking because we need very specific versions for specific openomf builds.

And yes, please consider a better libdumb in debian, we've contributed a lot of fixes (as has kode54) that make things a lot better.

katajakasa commented 3 months ago

We ended up merging everything.