Patching Kode54 with CMakeList

[Eoin-ONeill-Yokai]

Hey, I've been trying to improve GME and game emulation format playback on linux via Gstreamer. I downloaded this repository in order to test out this build of GME with the existing gstgme plugin on gstreamer-plugins-bad. This seems to work better than the existing libgme.so.0 and libgme.so.0.6.2 that is available on the Ubuntu repository (which I think is based on the old blargg GME codebase.) This can build on my kubuntu (bionic bever) system with no problems although I wasn't able to test every format entirely.

So I was wondering if you would consider creating a patch for this and applying to Kode54's code so we can get all the development of GME happening in one centralized place? ( kode54/Game_Music_Emu#6 ) Or is there anything else that needs to be done in order to send a patch in?

[wyatt8740]

Hi, thanks for asking. The CMakeLists.txt that I worked on is not really production-quality, and indeed was my first time using CMake for anything other than building other peoples' code with build systems that they had set up themselves.

The main problem is that I still need to get all of the different options partitioned off so that individual platforms/chips can be enabled or disabled at compile-time. Right now most of the stuff is just lumped together.

Also, as Kode54 decided to take the time to actually remove a vendor-neutral build system, and then took the time to add support for a vendor-locked one, and after that wrote windows-specific code which I had to dive into and fix, I an nervous that I'd be stuck with responsibilities that I can't really afford time for right now but would feel obligated to perform anyway.

I suspect that if it got pulled in, kode54 would not maintain the cmake build system at all - it would break when he added some new gadget to his version in MSVC, a user would complain, and he'd point to me and say that he only uses MSVC and doesn't want to maintain the CMake system (As he spent all that time and effort moving off of it, I'd assume this is his response since it's happened before.) Then I'd get to pick up the pieces or else feel bad about ignoring someone's request for help.

I don't really have time for that kind of drama at the moment. I really just did this for my own purposes so I could play some of my chiptune stuff with more accurate emulators than the old Blargg library had.
If either I get time, or someone else gets the cmake system ironed out more, I'd be OK with doing a pull request, but I'd really like it if I didn't have to maintain it after that point.

If you want help with anything though, I'm happy to assist, or at least attempt to. And at some point I might try to fix up CMakeLists myself, but no guarantees. Pull requests welcome :)

(sorry for getting so verbose.)

[Eoin-ONeill-Yokai]

Hey there, thanks for the quick reply.

Hi, thanks for asking. The CMakeLists.txt that I worked on is not really production-quality, and indeed was my first time using CMake for anything other than building other peoples' code with build systems that they had set up themselves.

The main problem is that I still need to get all of the different options partitioned off so that individual platforms/chips can be enabled or disabled at compile-time. Right now most of the stuff is just lumped together.

I'm in a similar position with CMake. I've used it for some small projects and I have used it to build other open source projects but I'm not super experienced creating complex cmakelists with tons of options from scratch.

Also, as Kode54 decided to take the time to actually remove a vendor-neutral build system, and then took the time to add support for a vendor-locked one, and after that wrote windows-specific code which I had to dive into and fix, I an nervous that I'd be stuck with responsibilities that I can't really afford time for right now but would feel obligated to perform anyway.

I suspect that if it got pulled in, kode54 would not maintain the cmake build system at all - it would break when he added some new gadget to his version in MSVC, a user would complain, and he'd point to me and say that he only uses MSVC and doesn't want to maintain the CMake system (As he spent all that time and effort moving off of it, I'd assume this is his response since it's happened before.) Then I'd get to pick up the pieces or else feel bad about ignoring someone's request for help.

I totally see where you're coming from on this, and I think you've raised some very good points.

From a distance, it seems that Kode54 is mainly focused on extending Blargg's original code in his own way, which happens to be a bit Windows-centric. Of course, that's fine with me, as he's clearly done some great work for GME and I don't expect everyone to care about multi-platform support if they mainly develop for and use a single platform. (Though, this is based completely on an assumption, and I'd be interested in talking to him about this.)

On the other hand, GME is a great library with multi-platform origins, and I feel that it's important that it stays that way in some capacity; which means that it needs some kind of 'home' where it is maintained in a multi-platform friendly way. That may end up being a change to the way that Kode54 works, or a separate "xplatform" branch in his repository that uses cmake and requires new features to be merged in over time, or a stand-alone fork that's maintained separately. This would all depend mainly, of course, on how Kode54 personally feels about it and what he wants to do.

I don't really have time for that kind of drama at the moment. I really just did this for my own purposes so I could play some of my chiptune stuff with more accurate emulators than the old Blargg library had.
If either I get time, or someone else gets the cmake system ironed out more, I'd be OK with doing a pull request, but I'd really like it if I didn't have to maintain it after that point.

If you want help with anything though, I'm happy to assist, or at least attempt to. And at some point I might try to fix up CMakeLists myself, but no guarantees. Pull requests welcome :)

(sorry for getting so verbose.)

Understood. The last thing I want is to create any drama. I'm very much with you and I'm only really interested in improving the chiptune support on Linux in any way that I can. Similar to your experience, I went ahead and patched support for properly importing SPC and VGM files into Clementine (clementine-player/Clementine#6082 and clementine-player/Clementine#6089) when I noticed that VGM support in GStreamer (Clementine's backend) was kind of lacking, due to using the old Blargg library. I spent a while going down the rabbit-hole of what was currently being used in programs like foobar2000 or deadbeef, which ultimately lead me to Kode's (pretty awesome) fork, and your super useful cmake fork which really made it a breeze to build and replace the blargg libgme with the kode54 version.

Now, that works pretty well for my personal needs. But I'd also like to do whatever possible in my free time to help make this improved GME more accessible to others (on Linux or elsewhere); which probably means, better cross-platform building, improving gstreamer support, patching other popular music players wherever possible, putting together basic documentation, etc.

At any rate, I'm not trying to put you on the spot or ask you to maintain anything! I just found your repo via an issue on Kode's repo, built it and replaced the blargg lib (which much improved chiptune playback on my kubuntu setup =] ), and I thought I'd follow up on whether you were planning on opening a PR with kode or not. I definitely see where you're coming from on this.

As for being verbose, I'm leaving you with a wall of text here! Anyway, thanks again for the response and the helpful cmake script. I'll also have to consider what I want to do from here.