Multi-target project exporters


actually, spoke to soon. Still have the issue that if I include another VS Studio project in the workspace, e.g. a static library, only the cpp files show up. Not even sure if this is anything to do with how you’re doing things really, seems like a wierd VS issue.

Anyway, this is how it looks if I open the library on it’s own in VS:

Now, if i add that static library to another JUCE created project with vst, standalone etc and expand it:


Is this a JUCE generated project? I can’t really see why the header files would be filtered out. Normally, you would need to create .filters file to exclude header files in the browser if they were added to the project.


@fabian Thanks for making that change!

As for helping new users with finding the source code: how about adding a single “ReadMe.txt” file at the solution level, which then explains about the structure of the solution/projects and where to find the various source code files. It would be a small file, and only one, so it wouldn’t be in the way of experienced users, but it would still call for an action to read it for new users, especially if it’s the only top-level file. IIRC, Visual Studio even used to do that as well when you create(d?) a native Win32 application project.


yes, this is another JUCE generated project from Projucer.

It’s very strange and as I say, I think it’s a VS “funny”. I was convinced it was fine last night when I checked, but today it wasn’t, but now after a restart of VS the .h files are appearing again.

I’m wondering if it’s something to do with having VS open with the included project for the library, then using Projucer to update the library (at which point the open VS asks if the contents are to be reloaded) and this is screwing up… Anyway, I’ll keep an eye on seeing if I can figure out what causes it…


Should this update also include the changes to the Linux makefiles? Doesn’t seem to be the case so far.

Thanks a lot for this new concept, I was looking for something like this!


What feature are you looking for? Multi-target projects have been supported in linux Makefiles for months now.


I’m referring to the phony targets you mentioned (e.g. “make VST”). Can’t see something for this in the makefiles. In case this should work already, is there something I might have missed to enable this?


I think my pessimism was justified, still getting weird messages (not so often than before the change)

The only solution is a separate solution for every output format.


I noticed this as well. I wondered why this design was chosen, it would be better to keep the editor and processor in the shared project, as it is part of it. And Intellsiense can still find the header definition if we wanted to play with the plugin projects (bu who in their sane mind would do that?).
I suppose this was done to simplify ROLI’s job, not the user of ROLI tools…


You can easilly do that by yourself. Duplicate the projects and remove the unneeded project from each solution.
I neever had this error message, and if you are not compiling the .cpp in your subprojects, you shouldn’t need another solution. The split as it has been done is the best idea (just one call to build everything in one mode, Debug or Release), it’s just that the files should have been in the projects from the start, it is quite immediately obvious that shared code is the only project that has a relevance in the build.


That would make a project practically unmaintainable without continuous usage of Projucer, which is not feasible if one has third party dependencies that don’t fit the support provided by Projucer itself.

Imagine how tedious and error prone it would be having to manually add a source file to every one of those solutions…


Well, what should we do?


One solution, source code inside their respective projects.
I don’t understand the issue you have, it seems something else than compatibility of this design with VS. CMake has been doing this for a really long time and what you describe never occured on any of their generated projects, so I will discard it as a bug somewhere in the implementation (either what projucer creates or how you modified it).


What? Wait, that’s exactly what the Projucer should be doing.

@chkn Can you make sure that this is a fresh project, i.e. by, for example, deleting the build folder. The reason is that I was still getting these errors due to the hidden files that VS creates (which are sadly in a proprietary format).


What I wanted to say is that the source file is first referenced in the solution than in a project. But as far I’ve understood, you changed this on develop, so should be there in the next release.


Okay, i remember i already deleted it once, but i do it again, delete the whole build folder, inclusive the Project folder, and regenerate the project. I will keep you up to date.


fabian, could you give this a quick look?

I can’t find something like the phony targets for a specific plug-in type in the Linux Makefiles. That means, “make VST” does not work for the audio plugin demo (latest devel), or for any of my projects (also not after re-saving with the latest Projucer).

Of course I can compile all plug-in types and delete what I don’t need, but I’d like to have a cleaner way for this.


I’ll add this. For now, you can also just use make builds/MyPluginName.vst to build only the vst.


This is now on develop.


Great! Works good, thanks a lot!