Introjucer relative modules location?


#1

Any plans to make the “modules” file location in the introjucer relative?

I found a need to say …/juce/modules in an introjucer project that I’m working to accommodate for a continuous build server that might have a completely different file structure from the dev side.


#2

Never-mind, it’s doing what it’s supposed to now after I deleted the Introjucer settings?

This was very odd; I created a project, opened it in XCode and the “browsable” no copied module files were in the project but the path for the individual module source(s) was all out of whack in relation to the xcode proj. After deleting the settings, relaunching introjucer, setting the modules folder location, and saving the project, everything seems to be fine now.


#3

Nope, happend again. Seems like when you create a new project the paths for each module source is relative to the introjucer executable.


#4

Ok… well, I’m about to overhaul that bit of the code anyway, I’ll figure something out for it.


#5

well, my workaround does work but is a pain.

Can you make it so that the “Source” folder in the various generated projects be right under the Project;

So right now this is what we get:

Current:

MyProject (This is the .proj Xcode/VS) +MyProject (Why do we need this folder?) |+Source +Juce Modules +Juce Library Code

Preferred:

MyProject (This is the .proj Xcode/VS) +Source +Juce Modules +Juce Library Code


#6

I seem to remember having some problems creating that structure in MSVC for some reason, but yes, it’s something I know about.


#7

also, what’s the best approach in handling new user written module code? So for example that UIScrollView replacement on iOS only I did, do I just add a module info file for it to be included? BTW I’m really getting use to the Introjucer workflow now, creating files in it reopening in xcode, kicking off builds in a vm in VS etc.


#8

I need to write something up describing how to create user modules… I’m not quite finished with the format though, so will explain it better when I’m finally happy with it.


#9

So anyway to do a relative path for the modules folder in introjucer?


#10

Well, not really, because what would it be relative to? That path isn’t stored in the project, it’s just a global setting.


#11

ok so this is the project layout I have; juce is a sudo git submodule inside my project tree. Currently the modules folder is stored as /Projetcs/Client/juce/modules, but this will break when on another dev’s machine because they might keep things setup a little differently. Is it worth investigating a global modules path and an per project .jucer path, so the user can set this up if not it will user the global path. You might be asking “why in the world would you want to keep the juce library part of the projetc tree?” well firstly we are going to be making tweaks to the library, second sometimes it is required for a project to be self contained to avoid any hand-holding when new devs come in, they just pull/clone the project and they’re done.

-Thanks


#12

I very much do expect people to keep their juce modules in their project trees, but not by doing it manually.

What I’d suggest would be that everyone would have a “master” modules folder on their machine that contains the latest versions (or your in-house hacked version, etc). Then, in the introjucer’s settings for each project, you’d select the “copy files into project” options for the modules, and the introjucer will then make a project-local copy of the master modules. That way, each project has no external dependencies, but when your master modules folder is updated, you can choose to re-save each project if you want to update it from the master copy.