I am hoping I can make myself clear here, as I am not fluent in Juce-eze.
This is for Windows 10 x64 only.
Since it has now been mandated that all plugins should no longer link to the static CRT
I am assuming one can create a JUCE.dll.
When I say JUCE.dll I want to build a .dll from the components that typically appear within a ProJucer
project within ‘JUCE Library Code’ and ‘JUCE Modules’.
I have multiple plug ins that I want to have all utilize the JUCE.dll rather than static linking.
I have looked at JUCE\extras\WindowsDLL I see that it builds a static link library.
Clearly I am missing something here.
I have read almost every forum post with ‘Dll’ in it and am still confused.
Just don’t do it. It’s not worth the hassle. Unless you have a use case where like 100 plugins would otherwise have their own copy of the Juce code linked statically.
I think it’s been the general consensus one shouldn’t bother trying to use Juce from a DLL. That use case just hasn’t been the intended one for Juce, at least the past few years. Therefore, it is a “hassle”, when even the Juce developers don’t really support it.
I am not sure what exactly is the purpose of the “extras/WindowsDLL” in the Juce source tree. Maybe they are looking into officially re-enabling that way to use Juce now? (I can’t test what the Jucer project ends up doing since I am not at a Windows machine now.)
The project does in fact create a static link library.
I am simply guessing here, but perhaps:
One wants to create a Juce (sort of) ‘Application’.
One wants to have the whole thing itself within a .Dll.
The code within the .Dll would link to the static lib created by the WindowsDLL project.
If this is true then it of course would not be what I am looking for.
Yes, it is true that everyone generally says ‘Don’t bother trying’.
My question is Why Not?
I understand in the past on Windows operating system memory allocation between
a .Dll and the code using it was problematic to say the least.
But again, this is for Windows 10 x64 only. I believe this resolves most
of the issues surrounding this problem: This Post
So again, Is there a reason what I want to do is not possible?
“DLL hell” isn’t specific to juce, it’s a long-standing problem with C++ in general.
It’s just a total pain if you want to have C++ classes inside and outside of a DLL whcih interact with each other in a non-trivial way, mainly due to cross-module heap management and memory layout issues. That’s why COM-style patterns exist and are used for plugins APIs, but nobody in their right mind would write a whole library with COM style.
JUCE does actually make some allowances for its classes to be marked as exported/imported, and some people do apparently work with it like that, but I agree that it’s probably not worth the hassle.
I think that if your use-case is that you need 40 plugins which all appear as individual binary files, an option that avoids a lot of the DLL hell might be to build a single big DLL which has all the code in it for everything, and then generate minimal loader wrapper DLLs which just invoke it in one of the 40 different modes, so keeping all the tangled C++ stuff in a single build.
IIRC it was just there kept around as an example, and so we could check that the DLL build didn’t get broken… which clearly failed if it’s not building any more! Would have to check with Tom as to whether we even include it in our CI or not.
Xenakios:
I am glad to see other developers as curios and un-afraid as myself!
Not to kick a dead horse. None of what is being said here is foreign to me. But I am anal about being thorough, even is a forum post.
The WindowsDLL does in fact build under Visual Studio 2017. I have no idea why Xenakios cannot build it. Perhaps it is ‘Site Specific’.
I did this:
Within the project change:
Configuration Properties->General:
Configuration Type: Dynamic Library (.dll)
TargetExtension: .dll
Linker->General Output File: change juce_dll.lib to juce_dll.dll
Start a command prompt (cmd)
(Because 64 bit compile tools are required, one is probably running 32Bit) from a command line:
cd C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\Tools
VsDevCmd -arch=amd64
-One must ‘Clean’ the project because you probably attempted it with 32Bit tools
MsBuild WindowsDLL_StaticLibrary.vcxproj /property:Configuration=Debug;Platform=x64 /t:Clean
So, it builds successfully. Whether or not it is usable is another story.
Some statements. Feel free to correct any incorrect statements:
1.) The WindowsDLL project is there to test the building of the juce code that actually utilizes JUCE_DLL_BUILD.
2.) The only code within the JUCE code base that utilizes JUCE_DLL_BUILD is represented by the projects identified under ‘JUCE Library code’.
3.) Note the missing modules.
Jules, I would suggest one does not remove the WindowsDLL from the CI as there are still adventurous soles out there. Perhaps a readme is enough for clarification of it’s purpose. One should of course include verbiage such as ‘If you are brave enough, this is not supported, you are on your own, please do not post to the forum questions,…’
