Alternate Introjucer workflows


#1

Fully relying on Introjucer for project management is very appealing to me in many ways, but I've run into various miscellaneous issues with Introjucer not supporting everything I need or want.  I've read quite a bit of debate on this forum about the pros and cons of relying totally on Introjucer vs. not using it all, as well as static linking vs. including the sources directly using via the module cpp.

In many ways I like the recommendation of including the module cpp files directly in the project and handling the project management myself from within the IDEs.  A problem with that approach that some people have mentioned is not being able to easily browse, search and set breakpoints within the JUCE source.  Of course, it's possible to incorporate all of the source files in your project, but JUCE updates could add, delete, rename and move files, so the project could easily become out of sync. 

A solution that I've found is to put all of the module source files in it's own project that is generated by Introjucer, and include that in the MSVC Solution and in XCode as a sub-project.  This is essentially a dummy project because none of these source files are built or linked in with the main project.  But this dummy project allows you to easily browse, search and set breakpoints.

Then when I'm ready to take a JUCE update I use Introjucer to recreate the dummy modules project, but I leave everything else as is, unless there's some sort radical change like a module cpp is renamed or something like that.  There is only one other step I have to do by hand which is delete everything from the modules project, except of course the modules.

I tested this out on Windows and breifly on the Mac and it seems to work well, but I wanted to get feedback from others on this approach.  Maybe there is some major downside I haven't considered.

I also wanted to throw out the idea that Introjucer could have a modules only project type and then the modules project could be created in a single step.  

Thoughts?

 

 

 


#2

A problem with that approach that some people have mentioned is not being able to easily browse, search and set breakpoints within the JUCE source.

I don't understand your point.. I spend most of my life doing all those things, in Xcode + Visual Studio.. (?)


#3

The approach I'm referring to is where you want to manually maintain your projects (no Introjucer) and you add the "Juce Library Code" files by hand (e.g., juce_core.cpp, juce_graphics.cpp).  In this case the "Juce Modules" files are not directly included in the project.  Of course, you could add the Juce module files by hand as well, but that would be a pain to maintain since there are more than a 1000 files and they are likely to change in some way with each update. 

Let me know if that doesn't totally make sense.


#4

(Yes, sorry, I misunderstood)