Re-add something similar to the shared_library_excludes config option

[4sensegaming]

I've tried using this in my basename.properties file to prevent the compiler from bundling Phonon in with my game. It uses no 3D audio, it runs fine if I manually remove the library, but no matter what I do or where in the properties file I put this option, etc. Phonon is still in there. It seems this option is documented but not yet honored by the actual compiler. I mean, Phonon alone is 50 mb on Windows, which is as large as two thirds of my game without it. :-)

[samtupy]

Hi,

This was an old option which existed before the system was able to automatically copy dlls based on the pragma plugin directive. It got removed at that time and unfortunately documentation has not been updated especially since we've not come up with a replacement yet. Preferably it would be cool if the game could determine whether to include phonon based on whether it was used or not or at least make it some sort of simple pragma.

We'll keep this issue open as a reminder to come up with some sort of solution to this.

Thanks.

[4sensegaming]

I'd like to share my latest findings, still related to the Phonon problem.
I've just compiled a Linux build on Windows and gave it to testers. Unfortunately, I can't test on Linux myself.
I've had to physically remove Phonon from the source folder before compilation and then put it back to avoid the forced inclusion of the library in the build. On Windows, this works fine. On Linux, the build throws an error and fails to run. Apparently, Phonon is hardcoded as a dependency on Linux. Is there a specific reason for that?
My game uses no HRTF, no 3D audio, and even no mixers or effects, because it's a port of a legacy BGT game that uses a heavily modified custom version of BGT's old sound pool.

[4sensegaming]

The exact same happens on macOS. Game crashes because it can't find Phonon.

[samtupy]

The reason is because making Phonon an optional dependency is actually a lot more work than just linking to it as one would with any other library. Currently I only have so much energy to develop the sound system, and it seems difficult to spend more energy on making phonon.dll/.so optional than on adding more features to the sound system. It works this well on windows because Visual Studio happens to include an easy to use delay loading mechanism that other platforms either don't have or don't have easily. Unfortunately Steam Audio keeps increasing the size of their official builds with almost every release for no actually good reason of which I am aware. I'd like to statically build Steam Audio ourselves and just make it part of the executable (much smaller), but steam audio broke their VCPKG port so for some reason it won't build on MacOS, and it would be slower anyway since the official steam audio uses a couple close source performance libraries to work faster. So TLDR the reason this has been low priority is because making Steam Audio optional on all platforms is programatically trickier than finishing up some of the missing features we'd like in the sound system while bringing only the benifit of reduced distrobution sizes. Trust me, I join the strangled frustration cries of those who wish their executables to be smaller. I do too, I really do. But this world is broken and one of the ways in which it's broken is by deciding that hard drive space doesn't matter one bit in 2026. Trying to fight that is possible, but after a while it starts to feel like trying to go without food for as long as possible to show people how cool you are for how little food you can survive upon Vs. eating something and getting actually useful things done in your life since all your energy isn't being spent fighting back hunger pangs. Though I genuinely do join all lamentations as to how big NVGT's distribution output is getting and while I do intend to see what I can do about it as the opportunity is presented, in the end the distrobution file size battle is really this unending war in which any victory is temporary and always tends to get undone or broken by one upstream dependency update or another, one library developer can flip one digital switch and make my 6 hours of making the binary and/or libraries smaller mean nothing all over again. So we can leave the issue here encase I can fix it, but it might be a while and might not fix everything as much as desired. No I don't like hearing it either. I wish enough developers still cared about disk space enough to make this a battle worth fighting more often.

Thanks.

[4sensegaming]

No, thank you, actually, for taking the time to write such a honest reply. I mean, if only more people were able to express their point on such a level. But that would mean they'd have to sacrifice the time required to stop to organize their thoughts for a while rather than doing something else.
I was suspecting the reason behind it to be something like this, and I totally get and respect your point. It's really not such a big deal in 2026, like you said, even though it should be. It will start to get more worrying once more people actually release playable games made in NVGT, where each of them will include its own copy of Phonon. It would be nice if it could at least be installed as a shared library, but then that would make the lives of the devs of those games that much more complicated again, putting obstacles in their way to delivering cross-platform portable builds. In any case, I was under the impression I could just omit Phonon entirely if I don't use it. Sorry about the confusion. I can definitely live with it for now, it's not a critical issue. :-)