Moderator: GZDoom Developers
make[2]: *** No rule to make target '/home/mchan223/doom/ZMusic/lib/libzmusic.so', needed by 'gzdoom'. Stop.
make[2]: *** Waiting for unfinished jobs....
[ 99%] Building CXX object src/CMakeFiles/zdoom.dir/zzautozend.cpp.o
make[1]: *** [CMakeFiles/Makefile2:984: src/CMakeFiles/zdoom.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
Matt wrote:In case anyone else has a similar problem: Mental's "-DZMUSIC_INCLUDE_DIR=..." stuff is supposed to be added to the cmake command in Graf's OP not entered as a separate command.
_mental_ wrote:MartinHowe wrote:is there some way to tell the gzdoom stuff where ZMusic is?
Read my post above, it's exactly about how to do this.
Rachael wrote:Git supports subrepositories. I think that's probably the best way.
Rachael wrote:I am sure those stories have some merit.
Another possibility is to merge all 4 repositories (Graf's prboom, gzdoom, raze, and zmusic) and have all contributors work on the same repository. I think even having different licenses for each isn't a problem, as long as they're all separated into their own subfolders. Then - all projects using ZMusic can simply use the same ZMusic on the same commit.
phantombeta wrote:You can't really separate PRs and commits by folder, so all the commits and PRs would be mixed together - and the mixed commits part would be specially hellish when doing anything that requires using the commit history, like tracking down bugs or bisecting.
Graf Zahl wrote:The idea here is to have a STABLE API, i.e. if new music formats get added they should become automatically usable without recompilation. I already made sure that the entire API is pure C and not a C++ class interface. If we start to treat this as an extension to GZDoom that can be changed at will, the entire idea will fall apart - this will especially mean that nobody else would ever be willing to use the library to play music.
Chris wrote:If the idea is to have a stable API that anyone else might want to use, there's a problem that a number of things are missing the ZMusic prefix. The enum and struct types are "bare" which have a non-negligible chance to clash with other users' code, some things also have generic prefixes (like SampleType_, SoundDecoder_, or CD_), or are lacking them (ChangeMusicSetting*, FindLoopTags), also creating chances to clash. A consistent and unique prefix to all public types, enums, and functions are necessary for a library expected to be reusable by others.
Chris wrote:Given all this about changes, I guess I would also bring up that the ZMusicCustomReader interface looks weird to me. Like an unnecessary hybridization of C-style virtual interface (with an opaque void handle for user data) and a C++-style virtual base class (a 'this' handle to base struct with pointers to functions, and user data as extra). Normally with a C-style virtual interface, the function pointers take the opaque void handle directly; there isn't a need to also give it function pointers for the other methods, which creates another level of indirection here. Alternatively, there is a way to 'extend' structs in C so the C++-style could work in C too, making the opaque void handle unnecessary.
Users browsing this forum: No registered users and 0 guests