An annoyance, which also leads to another problem (in a separate post)
When I already have the JUCE source tree somewhere and disable copying, IntroJucer creates a folder called “JuceLibraryCode” which doesn’t have any actual library code, just a tree of directory stubs leading to header files consisting of one-liner #include with relative paths:
why is this necessary? I already have a nice well formed JUCE tree with full sources parallel to my application directory:
IntroJucer already knows how to set up include paths. It would be a simple matter to just add the JUCE tree location to the include paths, instead of JuceLibraryCode:
Why didn’t IntroJucer just set “…\JUCE” instead of “…\JuceLibraryCode”? It has all the information it needs. Then I don’t have a bunch of useless header files pretending to be the JUCE headers but really just one liners.
The reason it’s not done like that is because it’s exporting projects that will be used on different machines, on which the juce folder may be in completely different locations. The JuceLibraryCode folder is more consistent though.
But this is all stuff that I’m going to review as I continue to work on it, so I might figure out a better scheme. I need to refactor it to support 3rd-party modules anyway, so it could all change.
That is good to hear…my use-case is that my repo has full JUCE sources along with all of the demo apps. Turns out IntroJucer is certainly the right tool for the job, but I would like to have the .jucer point at the JUCE tree in the repo (and the VFLib tree if it ever supports outside modules):