I would like to suggest a way of letting users customize project workflow via the usage of projects.
For some hobby programs, I’ve found that using multiple libraries with all their code under the same project renders the project… noisy. Make that extremely noisy.
I’m not sure how this applies to other IDEs other than Visual Studio, but my suggestion would be having the possibility of keeping JUCE within its own project, and having my application’s project separate from it if desired. (And having the ability to add other ones, too!)
Your workflow may differ, but I find this inconvenient.
The image I’ve uploaded is a mock-up example of the possible usefulness; a solution “using” JUCE and VFLib together, in separate projects. VFLib would obviously depend on JUCE, and MyProject would simply need to depend on VFLib.
As much as I dislike how IntroJucer forces certain things on me (and broken things like forced Link Time Code Generation and missing Debug information in optimized builds), the JUCE module arrangement does get one thing fantastically right. Static libraries are a pain in the ass, and the “unity build” style of source code organization makes them unnecessary.
Its easier to just include a handful of unity .cpp files (like juce_core.cpp) directly in your project than it is to maintain a separate static library project.
The problem with depending on the static library is that you don’t have any control over how it is built. So if you want to re-use a static library between two projects where the static library has different build settings for each project, its not possible.
I still add JUCE and VFLib static library projects to my workspace but I don’t link against them, they are only there for source code browsing. Which is why official support for the JUCE static library project should not be abandoned.
What I would like to see in IntroJucer is to get the bugs that I reported fixed. Like turning off Link Time Code Generation, being able to generate debug symbols in an optimized build. Also, it would be nice to have control over the Folder groups that get created. I’d like to be able to put my own groups directly at the root of the project instead of having them nested as a child of an IntroJucer generated group that has the same name as my project. I’d like to have control over where the Juce LIbrary Code group goes. And I’d also like the option not to generate those ridiculous .cpp files which pretend to be JUCE sources but really just have one #include with a long relative path leading back to the JUCE directory.
I just like to have 3rd party code as hidden as possible, but still easy to use/#include when necessary. I do like the Unity Build style of organization, but with multiple libraries - it doesn’t work; it distracts me greatly. I prefer having whatever is visible filter-wise my own code. This gives me absolute focus on what’s mine (as opposed to having several Unity Build sets of code sparsely laid out), and could care less for seeing other code 100% of the time (even if it’s just their folder/filters).
Since you’ve presented interesting counterpoints TheVinn, I’ve another suggestion in the same vein for Jules: having the Introjucer group 3rd party libraries into 1 folder (and IDE filter/folder), including JUCE itself. This eases hiding everything 3rd party by unifying such in one area, and doesn’t make it that much more difficult navigating to 3rd party code when needed.
Something like this: [attachment=0]3rd Party Library Organization - Unity Build Style.png[/attachment]
That would be a welcome improvement, especially if “My Code” and “More Code of Mine” were not nested in an extra group called “MyProject” (you left that out of your screenshot). I wrote about this in another post:
It would be great to a “README.txt” at the root of the project (instead of a child of the “MyProject” group).
It would also be nice if “Libraries” could be renamed, this way the order can be controlled in Visual Studio (for example, putting an underscore in front of it so it would come before “A Lot of Code”). According to Jules,
It sounds like Jules is open to these changes, but there are some potential conflicts and he doesn’t have the bandwidth to address it. Would you like to take a crack at it?
After looking at your link/other post, I see what you mean. If my suggestion were to come to fruition, I would agree with you considering this folder and filter unnecessary. In our present case, having the option of such being present or not would be better I would think; I like the freedom of choice to the extent of organization.
That would be also something worth having an option for. For my hobby projects, it’s cool to have one around. But even so, I can’t say I’ve a use for them in my solutions.
Indeed, that would be an issue! Not sure how other IDEs react to having a symbol though (like an underscore)… maybe Xcode, Eclipse, Code::Blocks or what-have-you that JUCE supports places such things last?
I’ll have a gander at the code that controls this shortly.
Well I’m not saying that IntroJucer should have some hard-coded “README.txt” feature, I’m just saying that I would like to be able to place individual source files at the root of the project and not inside a group. I’d also like to have a “LICENSE” type file of course (not sure if IntroJucer turns these into binaries).
Not sure how other IDEs react to having a symbol though (like an underscore)… maybe Xcode, Eclipse, Code::Blocks or what-have-you that JUCE supports places such things last?[/quote]
Well Xcode allows you to order child groups. If the IDE doesn’t support that symbol (and I doubt that its a problem but who knows) it could just be mapped to a space or something.
I just want to take what you said and shine a spotlight on it. Everyone has different workflows that suit them, there is no “one size fits all.” That’s why the JUCE static library project should not be removed, because it is needed in order to browse sources if you don’t use IntroJucer to create your IDE-specific project file.
IntroJucer features should always be well thought out, with a primary goal being flexibility for the developer. Anything that shoe-horns you into a specific mode is bad (especially requiring that the IntroJucer is used for practical development). Things that are general purpose and flexible are good, they can be used in ways that Jules didn’t make explicit and thus, server a larger audience.
