Suggestion: simplify selection of modules


#1

In the Projucer, I should just have to select which modules I want. No selection of module paths should be exposed to the user. After all, it seems like a bad idea to use modules that are out of sync with the version of the Projucer.

JUCE should just be distributed as the Projucer app (or an installer). The user should never have to worry about the locations of modules, as they would be included with the installation (much like how Xcode puts the C++ standard library inside its app bundle).

Does this make sense?


#2

It sounds like it makes sense, but the reality isn’t so simple. Obviously we’d like to have made it a one-click deal, but that wouldn’t meet the needs of almost any serious users.

Almost everyone who uses juce will be pulling it from github, not relying on the projucer to supply the files. We’ve even removed that option in the latest version. And most pro users will have juce in a custom location - perhaps a git submodule, or a predetermined location relative to their project. They’ll probably have multiple projects that may require different versions of juce in different places. And many people have custom or 3rd party modules that live in different locations to their juce modules. And there are other more obscure reasons why it’s done the way it is.

We do want to make it much easier to enable modules, and have been discussing exactly this topic recently, but it’ll never be possible to just remove the paths completely.


#3

Well, if you are pulling from github, you’d build the Projuicer with the appropriate versions of the modules, so all would stay in sync.

I guess users are pulling from github to be on the bleeding edge? I’ve just been downloading the releases.

The current UI seems to allow mixing of modules from different versions of JUCE. This sounds like a recipe for disaster, so why not just have a list of module search paths? That way, assuming no 3rd party modules, you’d have one path pointing to the modules folder (and have that by default be the modules that come with the Projuicer). And then for 3rd party modules you’d just add more paths.


#4

Honestly, I’ve thought about this a LOT!

The problem with paths is that in generating projects for different machines, it needs to know exactly where each module is for each target platform so that for example it can put the correct file paths into the Visual Studio project when you’re actually running the Projucer on OSX. Some of the paths will always be for other OSes, so it can’t just look in them to see where a particular module file lives.


#5

I’m sure you have. But occasionally, other people have good ideas ;).

Anyway, I now understand the constraint of being able to generate paths for modules that may not exist on the system.

Because modules are source you have to generate exact paths to the files. If instead modules were libraries (like with most SDKs) you wouldn’t have this problem, because you could have library/header search paths for each platform.