Transition to ZMusic as DLL

Here, developers communicate stuff that does not go onto the main News section or the front page of the site.
[Dev Blog] [Development Builds] [Git Change Log] [GZDoom Github Repo]

Moderator: GZDoom Developers

Re: Transition to ZMusic as DLL

Postby Rachael » Sat Feb 15, 2020 1:52 pm

I just did the 'make install' thing, wiped my build folder and recreated it and I was fine.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Transition to ZMusic as DLL

Postby Matt » Sat Feb 15, 2020 1:55 pm

Code: Select allExpand view
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
There's no ZMusic/lib/ folder.

Is this the cache thing people are talking about?
User avatar
Matt
Putting the XD into *xdeath since 2007
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: Transition to ZMusic as DLL

Postby _mental_ » Sat Feb 15, 2020 2:19 pm

Please read this post. Raze and GZDoom have identical configuration steps. Sorry, I cannot explain it simpler than that.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Transition to ZMusic as DLL

Postby Matt » Sat Feb 15, 2020 3:03 pm

Compiles now, thanks!

So basically the first option in your first reply, ignoring the "Setting ZMUSIC_INCLUDE_DIR and ZMUSIC_LIBRARIES directly should not require this." stuff...
User avatar
Matt
Putting the XD into *xdeath since 2007
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: Transition to ZMusic as DLL

Postby MartinHowe » Sat Feb 15, 2020 3:36 pm

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.


Thanks you guys; without the context of which directory to build ZMusic from and taking into account the 'shouldn't be necessary' I wasn't sure which went where. However, it makes sense now.
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: Transition to ZMusic as DLL

Postby Chris » Sat Feb 15, 2020 6:58 pm

This looks like it'll severely complicate working on and keeping keeping these projects up to date, since if there's any change to gzdoom or raze that relies on changes to zmusic (or vice-versa), you'll have to manually go and update the other without necessarily knowing ahead of time. Worse as someone who wants to work on zmusic, I might make changes that alters the API or its capabilities, how is this supposed to work? If I make the changes to zmusic and push them first, GZDoom and Raze will be in a broken/incomplete state until they're updated (and I wouldn't know how to update Raze, since I'm not at all familiar with its codebase). If I push changes to GZDoom first, it will no longer build until ZMusic is updated (at which point Raze will break until someone updates that). How are these projects supposed to stay in sync?
User avatar
Chris
 
Joined: 17 Jul 2003

Re: Transition to ZMusic as DLL

Postby Rachael » Sat Feb 15, 2020 7:47 pm

Git supports linked subrepositories. I think that's probably the best way.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Transition to ZMusic as DLL

Postby Chris » Sat Feb 15, 2020 7:51 pm

Rachael wrote:Git supports subrepositories. I think that's probably the best way.

I thought about that too, but anyone's who's ever used them only seems to talk of pain and torment.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: Transition to ZMusic as DLL

Postby Rachael » Sat Feb 15, 2020 7:58 pm

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Transition to ZMusic as DLL

Postby phantombeta » Sat Feb 15, 2020 11:26 pm

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.

That sounds like it'd be a massive mess, and honestly far, far, far worse than submodules. 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.
User avatar
phantombeta
In the meadow of sinful thoughts, every flower's a perfect one
 
Joined: 02 May 2013
Location: Brazil, South America, Earth, Orion-Cygnus Arm, Milky Way
Discord: phantombeta#2461
Twitch ID: phantombeta_
Github ID: Doom2fan
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Transition to ZMusic as DLL

Postby Rachael » Sun Feb 16, 2020 12:02 am

Bisecting will be hell too, especially to an outsider, if one of the submodules breaks.

/shrug

I am just trying to come up with ideas. They probably aren't great, but - who knows - better to try than not to, and with a few shots in the dark you might hit something viable - or god forbid, it might inspire some brainstorming in another direction.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Transition to ZMusic as DLL

Postby Chris » Sun Feb 16, 2020 12:14 am

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.

The problems is precisely with keeping PRs and commits separated between projects. If a change is made to ZMusic that depends on changing GZDoom and/or Raze, or vice-versa, a commit or PR would need to change them all at the same time to ensure it all stays working. Keeping them separate would ensure it breaks when one gets changed and not the others.

The alternative, submodules, would allow GZDoom or Raze to essentially hook to a specific commit of ZMusic, so ZMusic can be changed independently, and then GZDoom or Raze can update the commit it uses at the same time it requires the newer version. This should work in theory, but as I mentioned before, anyone who's ever used submodules seems to really not like them (I've never used them personally, so I couldn't say what the problem actually is).
User avatar
Chris
 
Joined: 17 Jul 2003

Re: Transition to ZMusic as DLL

Postby Graf Zahl » Sun Feb 16, 2020 1:04 am

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.

Right now I think the only area that may need some work is the decoder part - as you recently laid out. However, since I already use the DLL for a few private modifications of other games to hook in a music player the existing API should not be changed, only added to.
This entire idea of submodules and allowing modifications in ZMusic that require changes in GZDoom and vice versa is something that should be avoided, it's not how I want to maintain this.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Transition to ZMusic as DLL

Postby Chris » Sun Feb 16, 2020 3:15 am

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.

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.

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: Transition to ZMusic as DLL

Postby Graf Zahl » Sun Feb 16, 2020 3:23 am

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.


Them it needs to be fixed. The first step was to get the code separated and working, the second will be do do the interface correctly, and since you already said that you wanted some rework of the sound decoder I didn't put too much effort into that until the specs are clear.

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.


Yes, that part suffered from scaling down a truly virtual C++ class and should be cleaned up.
But again - I wanted the code to be separated first before cleaning up the interface - it was already problematic to have two projects depend on this and not being in sync because they had their own copy of it.
As long as it remains undocumented and only used in two public projects this all is easy enough to manage, so any input, both in form of comments and PRs to improve things is welcome. I already created a new branch for that.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to Developer Blog

Who is online

Users browsing this forum: No registered users and 0 guests