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

Libretro-common resync - some things we need #24

Open
inactive123 opened this issue Jun 5, 2020 · 7 comments
Open

Libretro-common resync - some things we need #24

inactive123 opened this issue Jun 5, 2020 · 7 comments

Comments

@inactive123
Copy link

inactive123 commented Jun 5, 2020

Hi there,

following earlier conversations with @alucryd , I'm fine with resyncing libchdr so that libretro-common, RetroArch and upstream libchdr are all on the same page again.

However, if we may humbly make some tiny requests, there are a couple of things still preventing us from not having to make a single edit to the sources. If these could be addressed then we could get rid of our own fork -

  1. Uniquely namespace all source file names. These files get statically linked with libretro cores. There are compilers/toolchains where having two source files with the exact same name creates a problem where only one will be linked. You can see here how we basically renamed all files for libchdr and prefixed 'libchdr_' to it.

https://github.com/libretro/RetroArch/tree/master/libretro-common/formats/libchdr

  1. Header includes. On our shallow fork you see that we try pulling from the system directory first -

https://github.com/libretro/RetroArch/blob/master/libretro-common/formats/libchdr/libchdr_bitstream.c#L12

For various libretro cores and for RetroArch itself, we set several include dirs for header files. Again, this is a small thing, but the way it is right now in upstream can pose problems on certain compilers/toolchains we care about.

So far, these are the only two things I can think of. They should be relatively small requests hopefully.

If any additions have been made to libchdr in any of the libretro cores that have not been upstreamed yet, hopefully @alucryd can help us out in that endeavor to make sure that all these missing parts are submitted to you as PRs so that we can finally have one central libchdr version with all the features and we no longer have to make these forks.

Thanks for reading.

@rtissera
Copy link
Owner

rtissera commented Jun 5, 2020

@twinaphex I'm fine with the changes themselves you request.
Out of topic, have you thought about using git submodules for libretro-common and possibly bundling libretro-common as a submodule of various libretro cores ?

@inactive123
Copy link
Author

Nah we want to avoid that at all costs. Libretro cores should only bake in the files from libretro common that they need.

Also not a fan of submodules for it or subtrees, we want building to be kept easy and the entire point is that a dev only uses the few parts they actually need, it should not be like some big kitchensink API/SDK like SDL.

@negativeExponent
Copy link

@rtissera
Copy link
Owner

@twinaphex requesting changes have been applied in latest master of @rtissera libchdr repo.
Let me know how to move on.

@rtissera
Copy link
Owner

rtissera commented Nov 4, 2021

@twinaphex @negativeExponent can we close this as well ?

@rtissera
Copy link
Owner

@inactive123 @negativeExponent @LibretroAdmin sorry for the ping again, can we close this issue now ?

@negativeExponent
Copy link

dunno if libretroadmin ontacted you recently, but ive tried to use this latest commit for libchr in libretro and its causing lots of changes to be done. it was initially merged in the PCE core but due was reverted back. dunno what libretroadmin found out to fail in doing a full libchrd update causing it to be reverted instead.

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

No branches or pull requests

3 participants