#include directives for ".cpp" files? Source files which appear in the .vcxproj but don't get compiled? Secret macros like "START_AUTOINCLUDE" for home brew file massages? Not good...
jules wrote:That compile error was just a typo, I've already sorted it out.
jules wrote:Well, those are some pretty silly things to dislike. The way I've structured the modules internally works extremely well, but you shouldn't be poking your nose in the internals anyway!
jules wrote:The only thing that I feel I need to defend would be the fact that it adds non-compiled source files to the project. That's optional, and the files are there as a handy reference, and to make it possible to debug them more easily. When you have a load of header files in your project, they're not compiled either - this is no different in principle, they just happen to have a different file extension.
Well, those are some pretty silly things to dislike. The way I've structured the modules internally works extremely well, but you shouldn't be poking your nose in the internals anyway!
steffen wrote:I really do like the modular approach and hope I finally find the time to clean-up some of my stuff and contribute it as a third-party module. ... The problem for me with the modules branch is that the VisualAssist source parser often gets confused by the includes and duplicate classes in the project.
Is anyone else using VisualAssist having the same problems?
Well I am building the "juce static library" Visual Studio 2010 project from the modules branch.
chkn wrote:Well I am building the "juce static library" Visual Studio 2010 project from the modules branch.
I wouldn't go the static library way anymore, just let introjucer build your end-project, it makes things easier.
You can make a script which actually downloads the module-tree, automatically compiles the introjucer, and resaves you projects with the introjucer. Very comfortable when it comes to porting.
chkn wrote:Is anyone else using VisualAssist having the same problems?
Yes, there are some issues with Juce, but theese are bugs in Visual Assist (and the problem is not the duplicate of classes, in my case). I reported some of them in there forum, please do also
NO NO NO!!!
This is exactly what I've been against all along, the requirement that I MUST use IntroJucer in order to build. I don't want a script to "automatically" do anything either. This is going straight in the direction of "autotools" (which I also find cumbersome).
NO NO NO!!!
Something I've been thinking about doing is to provide another mode for the introjucer, which will let it create a "module collection" (better name needed..) instead of a project. A module collection would basically be a folder containing a bunch of modules and a generated header file for them, containing whatever options are needed. This could then be used by multiple projects if they all need the same module setup. A module collection could even be done as a static library, so you could compile it once and link to it from multiple projects.
chkn wrote:- if you are using Introjucer generated projects you always have a constant initial base of project settings.
If you start new projects, or port them, you also automatically have the right settings.
If you are using JUCE-static library project, you always have to be sure the makros/parameters are the same for JUCE header files
Users browsing this forum: Google Feedfetcher and 2 guests