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:
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.
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:
Have my own module repository with modules, apps etc. in it
Create a symlink to the module
Place the symlink in the JUCE ‘modules’ directory
Open the Introjucer, my module is there in the list along with all the JUCE ones and the config flags are correctly recognised
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.
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.
In Terminal navigate to AppletJUCE/modules
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 (https://github.com/vinniefalco/AppletJUCE/tree/master/JUCE), 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.