Building without Visual Studio possible?
Opened this issue · 4 comments
Hi there, do you have any advice regarding building this without VS? Particularly on non-Windows platforms, and especially particularly for ARM, as I'm trying to include the library in an Android app.
I have been able to build blarrg's version of the library, which uses CMake, but you seem to have fixed many of the issues I've encountered using it. Any help you could provide would be appreciated.
Blargg's CMake files should be good to go, so long as you add all the new files. I welcome a pull request against both master and the vgmplay branches, as well as any CMake files that need to go into the vgmplay repository.
What MSVC version is required for the project files? MSVC9 does not see them as a supported type.
I might try to adapt the CMake files. Is there any list of changes (changelog) or list of new files?
Our software (Zelda Classic) relies on GME, but we use a woefully ancient build of it. I'm not sure if the APi itself has changed in any way that requires us to change code internally to our software, or if the new library can directly replace an older one.
A general makefile for MinGW, or other build files would be nice; as would documentation. I do not see any /docs path now, which used to exist.
I shoehorned this version of the library into building in linux with CMake. It might still need some work to build on other platforms, but right now it's working for me (tm). In the past I have made CMake work from MinGW, so you could try that.
https://github.com/wyatt8740/Game_Music_Emu
I've only found one ABI breakage so far, which my build has a stub function for to prevent crashing. It relates to the transition to the new higan/bsnes-based SPC library - gme_enable_accuracy().
In my version, this is a stub, which allows for binary compatibility with GME 0.6.2, as packaged in Debian.
@ZoriaRPG forgot to ping you.
It still needs some work, I think, but for now I've been able to use it with ffmpeg on my linux box. And I think, but am not sure, that it will work in MinGW. If it doesn't, I'd look in blargg_common.h for any type incompatibilities. I think MinGW has stdint.h, so that shouldn't be too big of an issue.