Howdy,
I’m new to Introjucer and I’m trying to set up a git project containing .jucer files but I’m not seeing a way to work with user defined settings in .jucer files. Is there a way for Introjucer to read settings from a separate file that can be added to .gitignore so we don’t have people constantly writing their local include directories into the repository?
Cheers,
~ andy.f
There’s nothing in there to import settings, though I’ve never really hit this problem when working on shared projects… I guess that’s because I tend to always set things up using relative paths.
I’m not much of a git expert, but am fairly sure you can set up a local branch in such a way that people can auto-merge their local changes into the main .jucer file.
So is the standard practice to create the different targets in the .jucer file (Xcode, VS2010, etc.) and commit the project files generated by Introjucer into the main repository (.xcode, .sln, etc.)? Do you even put the .jucer file in the repo, or just the generated project files?
I’d certainly recommend putting the .jucer file in your repo. Personally I also put the project files in too because they’re pretty small, but that’s up to you, really.
This is what is confusing me. If I create a .jucer file with a VS2010 target, the juceFolder attribute points to a location on my machine that will not be the same on someone else’s machine. In my case it points to “…\usr\src\juce\modules”. If someone else clones the repo, they have to change the juceFolder location, and when they save the .jucer file it will get pushed to the main repo with their local juce folder’s location. How do we avoid this? I’m not a git expert either, so I usually just add a separate file to the .gitignore list that can be used to read local settings (like the juce folder location) without having to resort to some kind of git branching strategy. With no way of having Introjucer read from a separate file, I don’t know how to keep the local settings out of the main repository.
Perhaps you should be using the introjucer’s “create local copy” feature to put a copy of all the juce modules directly into your repo? That way the repo has no external dependencies, and it should work exactly the same on everyone’s machine. Plus, it means that everyone is definitely building against the same version of juce.
I am already using the “create local copy” feature. That setting does not effect the VS2010 juceFolder attribute in the .jucer file. Besides that, there are dependencies other than Juce for this project, too, and they can not be included in the repo directly. Also, if a new source file is added after the projects are generated, then they need to be regenerated which will require everyone to re-run Introjucer, which will mean everyone has to change the juceFolder attribute …etc, etc. Do you see the problem?
I’ve used project generators in the past like CMake and Qmake, and they have no problems reading settings from user defined files that can be ignored in .gitignore. I was just hoping Introjucer could, too. It would certainly make things easier if it could.
Yes - that’s actually the reason I check-in the generated project files. I’ve never hit this issue, because I generally just say that everyone should use the same relative file structure, which keeps everything very simple.
Adding a local file that could be included is a possibility, but TBH nobody’s ever asked for anything like that before. Not sure exactly how it’d work…
I see. So the workflow you use is one person generates the project files with Introjucer then everybody else uses the generated project files and they don’t touch the .jucer file. It’s seems limiting to me but if that’s how it’s designed to be used then that’s what we’ll do.
Cheers,
~ andy.f
I see. So the workflow you use is one person generates the project files with Introjucer then everybody else uses the generated project files and they don’t touch the .jucer file. It’s seems limiting to me but if that’s how it’s designed to be used then that’s what we’ll do.
Cheers,
~ andy.f[/quote]
…not exactly - if everything uses relative paths, and everyone has all their projects in the same relative tree structure, then anyone can regenerate the projects and it should work fine everywhere. I’ve done this with mixed Mac/PCs and it’s fine. But obviously I’ve no idea what your set-up involves - maybe you have complicated 3rd-party things to work around that make this approach impossible.
Not impossible but definitely undesirable. A separate config file for include and library directories would be easier to work with but I’ll think more on this and see if we can work out a way for everybody to use the same directory structure.
