Thumbs down on new modules project


#1

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…


#2

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

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.


#3

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 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?

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.


#4

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-git-branch-from-remote/

Bye


#5

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.


#6

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.


#7

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 :slight_smile:

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.


#8

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.[/quote]

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


#9

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 :slight_smile:
[/quote]

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.


#10

[quote]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).[/quote]

I couldn’t agree more.


#11

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.


#12

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 http://www.rawmaterialsoftware.com/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)


#13

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.


#14

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.


#15

[quote=“chkn”]- 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 [/quote]

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

Visual Studio Property Sheets

[attachment=2]vs_props.gif[/attachment]

Basing a Build Configuration on a Configuration File (XCode)

[attachment=1]xcconfig.gif[/attachment]

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

[attachment=0]property_panel.gif[/attachment]


#16

And, if you look at my dspfilters open source library, you will see that the three projects (the juce amalgamation, the dspfilters library, and the demo app) all have shared settings via XCode 4’s .xcconfig files:

[attachment=1]dspfilters_xcconfig.gif[/attachment]

dspfilters also uses property sheets for Visual Studio so you can look at that as an example, as well:

[attachment=0]dspfilters_vsprops.gif[/attachment]

So basically you are saying use IntroJucer, a separate application and additional step in the build process, to accomplish that which can already be done using the features built-in to both development environments, because you can’t be bothered to learn all the features of the IDE?

This is exactly why I want control over my project file, and why I do not want to depend on an additional tool to put my projects together. For the same reason I use C++ - I want total control over my projects so that I can optimize them fully to accomplish my goals.

Thumbs up to a better organization for Juce source files and modularized include structure, but thumbs down to requiring IntroJucer! And thumbs down to .cpp files which don’t get compiled - Qt Creator IDE does not have this feature of being able to disable .cpp files from compilation but still have them show up in the IDE, so we have taken a backward step in compatibility.


#17

I can answer that! No, I don’t want to know about Visual Studio style sheets. I also don’t want to know about Xcode configuration files, any more than I have to, or makefiles, or Eclipse whatevers etc.

IntroJucer is an excellent tool to start a cross-platform project. From there, I’ve found I have to tweak manually, but things are close enough that I can ‘work it out’ in most environments. I don’t find going back to IntroJucer to add each file is useful, since it inevitably writes over project settings that it couldn’t anticipate, but if I wanted to add a module, say, I could stomach it.

I agree, and I’m sure most do, that you shouldn’t ‘have’ to use IntroJucer. But you seem to be insisting that you ‘never’ have to use it. You may be on your own there. It’s a useful tool, and I think most of us are happy to use a fairly simple - the comparison to AutoTools is a stretch, IMO - tool to generate some projects occasionally.

By which I mean - you’re the 1%. It’s going to be harder for you to do things differently than the 99%. That’s the way it is. I’m certain you can handle it - I’ve seen your code, and configuration stuff. Please don’t get irate if your quest to get useful tools and structures removed because you don’t need them fails - I think most of the rest of us like them, or at least like to have them available as examples and to make examples.

And Merry Christmas!

Bruce


#18

I’m not suggesting in any way that we abandon IntroJucer, just that it should not be required in order to build.


#19

I’m totally agree with TheVinn here that the IJ should not become mandatory for setting up projects, and at my office here i’m not alone. So let’s up that 1% a bit shall we.


#20

I agree as well, Introjucer shouln’t be strictly required to write/configure/build a juice project.

I’m not very worried about the project file. From the small example I looked here the *.jucer file contains mostly introjucer settings and whether or not to compile a file. I guess something like that is necessary for introjucer to work with all those different platforms.

However, what worries me more is what I found from looking at the generated makefile. The file is simple enough to understand, so it could be hand-written, but there are some obscure magic numbers in it.
Examples:
“JUCER_LINUX_MAKE_7346DA2A=1”
$(OBJDIR)/MainWindow_499ac812.o

If those numbered objects and that numbered build flag are required then I would not be able to write a Makefile by hand. I don’t know whether they are required and I have not the slightest idea what “JUCER_LINUX_MAKE_7346DA2A=1” does.
Well, I’ll probably see soon enough whether it’s still possible to build by hand when I attempt to write my Makefile by hand and/or use an established build system (waf).