Thumbs down on new modules project

[TheVinn]

Well I finally got around to picking up the new "module" branch of juce and I'm not entirely pleased. First of all I got a compile error with GLintptr, something to do with OpenGL.

But more importantly, I'm not really feeling this non-standard arrangement. #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]

That compile error was just a typo, I've already sorted it out.

#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...

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!

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.

[TheVinn]

That compile error was just a typo, I've already sorted it out.

How do I pick up the changes? Also, I'm one of those people for whom "git checkout -b origin/modules" does not work (it does nothing). Where is the change log for the modules branch? What is the command to update my local working copy to the latest of the modules branch?

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!

Well I am building the "juce static library" Visual Studio 2010 project from the modules branch. In your defense, it does compile extraordinarily fast (a full rebuild takes 8 seconds). What do you mean poking in internals?

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.

How do I customize the project settings while still being able to pick up your project file changes? For example, if I want to build using the Intel C++ compiler. In the past, I have maintained my own .vcproj, and watched for changes in the changelog for added / renamed / removed files. But this has become more difficult now.

[iradic]

Hi, regarding git problems

I found that you need to use 'git checkout -b modules origin/modules'

Source:
http://www.wetware.co.nz/2009/07/pull-a ... om-remote/

Bye

[steffen]

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!

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. Also poking my nose in the internals is the best way for me to know if *I'm* doing something wrong when things explode, or I just stumbled on the occasional bug in the JUCE code base.

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. There are a couple of annoyances such that you often end up in the juce_module.h file when you want to quickly jump to a class declaration. It's by no means unusable, but the old structure was way superior for debugging, browsing and understanding the internal class dependencies with VisualAssist's features such as finding references or jumping between declarations and implementations.

I know the structure is done in a really clever way, and that compatibility with a specific tool isn't of any priority. But it'd really nice to get the same convenience while developing as with the old amalgamated/template structure.

Is anyone else using VisualAssist having the same problems? I haven't updated for a while, so maybe this is just a personal problem with my specific VS/VA version combination. If it isn't it would be great to know what's causing this, and I'd also be willing to inspect it further to find out if it can be somehow worked around.

[TheVinn]

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.

This is exactly my concern as well. Of course in "theory" including a .cpp file shouldn't be a problem but I know from my experience with Freetype that when you try to get too fancy with organizing source code, things tend to screw up. Specifically, the IDE.

[chkn]

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

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.

[TheVinn]

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.

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).

[steffen]

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

Good point. I'll check that forum and next time one of those annoyances happens, I'll try to take the time to find out what's actually going wrong. For me it's quite a miracle that c++ parsers work at all, so I wasn't expecting that these kind of issues can easily be fixed within VisualAssist.

[hladik]

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).

I couldn't agree more.

[jules]

I couldn't agree less!

Using the modularised stuff isn't really much different from using the old amalgamated files - you can still add the headers and cpp files manually to your project if you want to. The only real difference is that you have to add several cpps instead of one.

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]

NO NO NO!!!

THERE ARE some reasons i prefer the introjucer, instead of using juce static-library builds.

- 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.
(And if something is missing or wrong, don't change it in the compiler IDE settings, change the Introjucer for example viewtopic.php?f=2&t=7890 )
If you working with multiple projects/platforms you getting very fast in a compiler/linker parameter chaos, its good to have this point of reliableness.

-If you are using JUCE-static library project, you always have to be sure the makros/parameters are the same for JUCE header files and for the compiled library. In the end you are embedding the library-project somehow into your main-project, to simply change files for testing porpuses etc. , but what is the advantge over just using a introjucer project, THERE IS NO! (It only makes things more complicated)

[X-Ryl669]

Vincent, I can't bare the autotools nightmare, so I'm a bit on your side too.
However, the Introjucer is totally different than the autoshit stuff. It doesn't run 1000 test which could have been run in one, in order to determine the maximum command line size.
It just write Makefile and project file, without doing any auto-mess by trying to figure out the duration of your last sleep.

Frankly speaking, I don't like having to go back to the introjucer each time I want to add something in my VisualStudio project (so that's the reason why I ask Jules if he could monitor the project files for change in the IJ and read by the value it can support and apply similar change to all other project). That would be very sweet.
However, when I'm cross-building some Juce software, the IJ proved faster than modifying the Makefiles by hand + VisualStudio projects too.

[hladik]

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.

This would be really nice!
Please understand that I really consider essential to be the one who decides how the myriad of project settings are configured, how external code is to be linked, where the build files are written, which versioning system to use and so on.
I understand and appreciate your efforts with the IntroJucer (as I do with the great work you've done until now with Juce), but please, leave a way to let old programmers like me preserve their habits.

[TheVinn]

- 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

From what you're saying, I'm guessing you have never used Visual Studio Property Sheets or XCode Configuration Files??

Visual Studio Property Sheets

vs_props.gif (11.06 KiB) Viewed 3327 times

Basing a Build Configuration on a Configuration File (XCode)

xcconfig.gif (12.79 KiB) Viewed 3327 times

As you can see, my Visual Studio projects all use shared settings via property sheets:

property_panel.gif (16.63 KiB) Viewed 3327 times