IntroJucer: Unnecessary additional file group always added

Files and groups added to an Introjucer project result in an additional, unnecessary file group appearing in the corresponding platform specific project file, with the same name as the Introjucer project:


Instead, the file or group should be at the root of the platform specific project file, without creating the extra group:


Still a problem. I’m using IntroJucer for a demo project now, and I want the “VFLib Modules” group at the same level as Juce Modules. But Introjucer forces me to lose that level of control:


Forgive me, but isn’t there a “The Introjucer/Jucer” section in the forum for this kind of things?

UGH…yes. Unfortunately, there seems to be no way to move posts (and there are several of them).

Can a moderator please move these to the right sub-forum? Thanks.

When you add modules don’t you check them in the Introjucer module list? They then appear inline with all the other Juce modules. You should be able to keep them elsewhere on disk and just add a symlink to them into the Juce modules folder.


  1. How do I check a symlink into a Git repository?

  2. How do I make a symlink on Windows?

Also, these are my own modules not JUCE modules.

Symbolic Link. Its like an alias or shortcut on Windows but gets resolved by the operating system.

You shouldn’t need to check it into a Git repository. Just don’t add it (using ‘git add’) to any branch of Juce you may have forked.

Never actually done it on Windows but I think its a command line tool called mklink. I have created one on the Mac and it resolves correctly through a Windows VM shared folder.

This is how I do it:

  1. Have my own module repository with modules, apps etc. in it
  2. Create a symlink to the module
  3. Place the symlink in the JUCE ‘modules’ directory
  4. Open the Introjucer, my module is there in the list along with all the JUCE ones and the config flags are correctly recognised
  5. When I generate a project the header file gets included by JuceHeader.h & the cpp gets included in the “Juce Library Code” group.

[attachment=2]Screen Shot 2012-04-27 at 21.07.03.png[/attachment]
[attachment=1]Screen Shot 2012-04-27 at 21.06.11.png[/attachment]
[attachment=0]Screen Shot 2012-04-27 at 21.08.31.png[/attachment]

Now this is not an ideal solution but it has been working nicely for me for months.

What we really need is for Jules to add some kind of additional module search path option in the Introjucer. I know he has bigger plans for 3rd party module integration and they will eventually be able to be updated remotely. I also know there are only so many hours in a day and there are other, probably more important things that need doing first as there are only a few of us providing modules at the moment. I’m just using this method for the time being and waiting patiently for the module master plan to be revealed to us followers.

Nice hack you got yourself there!

The problem is that if I do this, then the resulting repository will not work “as-is.”

One of my design requirements is that anyone should be able to take a clone of my repository and be able to compile and run without any additional steps. That means, no configuration, no downloading of extra dependencies, and no creation of symbolic links. The same thing goes for the .jucer file, I want users to be able to open it up without first having to futz around with their JUCE source path. Unfortunately I suspect this is a problem (as most things with IntroJucer are, apparently I am the only one afflicted by these issues).

I don’t want to force anyone who grabs my repo to then have to also download JUCE and configure it in IntroJucer. Everything should just work. This means that if someone gets AppletJUCE on a CD-ROM they can actually use it on a computer without an Internet connection.

I see what you mean. You could just include your modules in the ‘JUCE/modules’ directory, they would then be recognised by the Introjucer but I’m guessing there may be some problem with all the other directories you have in the VFLib dir.

You may also be able to create some relative symbolic links. Try this on OSX, check them in and see if they resolve.

  1. In Terminal navigate to AppletJUCE/modules
  2. Create relative symbolic links to all your modules (or one as a tester) e.g.
    ln -s …/…/VFLib/modules/vf_audio vf_audio

I know this is a hack but in theory provides the behaviour you require.

A relative ‘Additional Module Directories’ option in the Introjucer would definitely solve this. I may put to Jules, it probably wouldn’t take that long to add.

We most definitely need “additional module directories”, because putting stuff in the JUCE tree is not an option. Even though I have put a full copy of the JUCE source tree into my AppletJUCE repo (, I cannot modify the contents. I’m using git-subtree to periodically squash all the JUCE commits in the upstream down into the subdirectory of my repository.

If I were to put symlinks (if that’s even possible) or other junk into the JUCE directory of AppletJUCE, git-subtree would either refuse to pull changes over it (since the commit log has a foreign entry) or it would overwrite anything I did, causing me to re-apply my changes every time I update JUCE.

Another problem with symlinks is that they can’t really be copied properly. If I put the working copy of my repo on a CD-ROM, the symlinks wouldn’t work right if the CD-ROM was copied to the local drive (they would either not transfer, or they would point to the CD-ROM drive). symlinks are not an option, really.

Can we please fix this? I would like to use IntroJucer for more of my projects but this is a stumbling block.