We need a solution for this, i now always need to clean and rebuild the whole solution, only when changing one line of code.
This seems a suggestion that goes in the direction of fragmentation… it would become a PITA to maintain for people not using Projucer.
I have another idea: do you think it would work if the single solution were composed of just:
- A project that builds the shared code
- Another project (just one) that builds all the plug-in formats as different targets? (each format should in reality be
splitted in two targets, one for Debug and the other for Release building)
I am not using Projucer myself for plug-in projects, so I cannot test this myself.
EDIT: I am getting old, I totally forgot that I posted more or less the same suggestion in this same thread back in February, and even in better detail: Multi-target project exporters - #5 by yfede
Unfortunately, then the discussion diverged and my post never got acknowledged.
I have another idea: do you think it would work if the single solution were composed of just:
Well, the question is, will it solve any of the current problems, this is not very different from what we have now.
A project for the shared code, and for every plugin-format a project.
The problem are the source files which are shared along the projects, and that SIMPLY DOES NOT WORK in Visual Studio
What I implied, is that no source files should be shared by the two projects: one builds the bulk of JUCE and the other builds the remaining files (format specific files, plus the user code) and links them with the result of the common project
Yes, but than, both projects would share the same header files too, and it seems that Visual Studio still might run into trouble to build consistent projects when these header files are changed. If your solution fix the current problems, sure that would be okay. The best and clean solution for me, and i think the majority of all jucers, is to have a single Solution and Project for each Plugin-Export format.
Well, not necessarily, in the sense that the headers don’t need to belong to both projects: outside of the JUCE world, when you need a header file you just #include it, you don’t need to actually have it added to your project in Visual Studio.
So, in my idea above one of the projects would actually contain those headers, while the other just #includes them.
Are there any news, how to fix the complete broken workflow on windows?
Currently working only on the mac is possible.
Whenever i change a source-file and start debug, its just random, if the changes exists in one specific build.
1 Like
While this is not a fix it seems to me as long as I have the VST project selected as the one to run (bold, Set As StartUp project) and only run a VST host, it is possible to work on windows and get all changes compiled in debug builds. The annoying error message is still annoying though.
I thought so too, but from time to time there are definitely issues with the current exporters, but you will may not recognise them immediately. For example i changed a template class definition, and that changes have not affect on the object files of the current startup project, because (i think) when i once opened the header file, from the top file structure under the solution, it may some how was connected to another project, i think thats the same issue where the annoying error messages comes from.
1 Like
Ok… now that I wrote the post I am getting the problem as well when changes are coming in from my OSX machine. Only doing a clean build seems to fix things 
This is of course super-annoying.
1 Like
Hmm things behave erratic. I guess what’s needed here is simple directions that force the problem to show up in one of the Juce sample plugins. Now things appear to work again here though 
Any news on this and do the problems still persists? I’m very uncomfortable with this multi target project structure. I even can’t find the project settings in visual studio 2015. Is it even possible to change compiler settings in the visual studio properties after a projucer 5 export or is all some kind of hidden now?
2 Likes
+1, the option to structure the files as Juce 4 did (i.e. source files are contained in the Visual Studio project, not in the solution) would be much, much appreciated.
I keep expanding the project to find the source code, only to see that all the cpp are thrown there with no further filtering, and the header files are not even there, so then I have to go expand the solution and look for them there… It’s quite irritating, and seems to be against all common practices to structure things in Visual Studio (or at least I have never seen a project structured like this before).
2 Likes
…and seems to be against all common practices to structure things in Visual Studio (or at least I have never seen a project structured like this before)
That’s exactly what i think too. And most time this means that we will run into issues sooner or later…
1 Like
Hi @kunz,
I’ve moved files back into the project and not the solution. For multi-target projects, the source files will go into the “Shared Code Project” and only the plug-in specific wrapper code will go into the respective other projects.
Before we release this on develop, we want to give it a bit more testing internally. One downside, is that new users may struggle to find the source code in a multi-target JUCE project - as only one of the projects (the “Shared Code Project”) will contain the source code. Any ideas?
Fabian
Hi Fabian
Thanks for getting back. I have no idea what the best way is at the moment. It sounds good this way. I have to take a closer look at it…
I would prefer a single solution for every export format, but yes, this may not everyones favourite exporter style 
.
PS: but its the most flawless
OK. The projucer has now been updated on the develop branch. Please give it a go and let me know what you think.
2 Likes
Looking good so far - my externally included static libraries now have the structure back, which is an enourmous help. I can search header files again!
thanks!
So far it looks very good 