Difficulties moving to new "module" branch

General JUCE discussion
#1

It seems that the new code I need is on the modules branch. I’ve not wanted to upgrade, because I’m thisclose to releasing, but I rather need the functionality there.

However, my attempts to move to this branch have been somewhat frustrating…

For one, all the git commands quoted here seem to be wrong, at least inasmuch as I understand git, and lead me inevitably to thousands of conflicts when I did a pull. The correct command on OS/X appears to be git checkout origin/modules, with no -b, and NO pull command - there seems to be no way to do a pull command without causing all these conflicts!

Once I finally got past that, I tried to build. Unfortunately, this also lead to thousands of errors that appear to be unrelated to my code, but having something to do with openGL. I reopened the introjucer and disabled all the modules that I wasn’t using - but now I get 40,000+ compilation errors seeming to indicate that absolutely none of juce exists.

Now, when I look at the files that the Introjucer has created, they seem wrong.

AppConfig.h has nothing in it, BinaryData.h doesn’t include any other .h files, and thus including JuceLibraryCode/JuceHeader.h results in a mass of errors.

I’ve been sitting with the JuceQuake page in front of me, but it hasn’t been helping - am I missing some other document?

#2

Some progress - I’ll post full details when I’m done.

I’m down to the fact that AppConfig.h is always empty, even though JUCE_USE_CDREADER and JUCE_USE_CDBURNER are set to enable in the IntroJucer, so I don’t see JuceCDReader.

Setting JUCE_USE_CDREADER and JUCE_USE_CDBURNER before I include any Juce files seems to do the trick - I still have some errors but they seem to be honest API changes.

I’ll report back later!

#3

Some more progress but now I’m at a complete dead-end. :frowning:

I fixed the various little API changes.

Unfortunately, the API of Component has changed in a way that I cannot get past.

I need to know when a repaint operation occurs to get around the fact that, as I reported before, my update rectangles on Mac OS/X are almost always the whole canvas instead of the tiny sliver that I’m actually dirtying. Without this hack, I’m repainting almost 100 times as much as I need on the Mac, so I do need it.

Before I was overriding internalRepaint. Yes, I know it’s internal, but I had no choice.

Now that method is neither virtual, nor protected.

I went in and changed the source, just to see what would happen. I did manage to get to the link phase.

I forgot that the “stock” version of the Introjucer doesn’t have my hack code to preserve the C++ code generation settings on XCode, so I get the usual thousand or so link warnings I get mixing Juce with other libraries. :-/ If I go forward with this branch, I’ll have to figure out some way to do this without hacking the Introjucer - probably :frowning: write a post-processor for Juce to fix the XCode again.

And then I get some 8,000 link errors because apparently none of Juce is being linked in at all. Looking at the link link, there’s no mention of Juce…

I checked to make sure that I had all the modules I need enabled. I have them set with “Add source to project: Make module files browsable in projects” ticked off.

Looking at the XCode project generated, I don’t see any new source files, or any library linked, so I simply have no idea how to start…

So this is opening a huge can of worms for me. And it’ll be even worse on the Windows side - our (ex-) Windows build person was unable to figure out how to get the old Introjucer to spit out the right options to link our libraries in Visual Studio, so I have to update the Windows build “by hand”. This might be an easy fix - but probably isn’t.

I’ll try again in a few months!

#4

I’m struggling to think why it’d give you so much trouble… I’d be happy to spend some time figuring it out with you if you want, I’d like to know what I could do to iron out any bumps in the process.

As regards the repaint stuff, there’s now a thing called a CachedComponentImage which lets you do all manner of paint intercepting/caching for a component - you could use one of those to intercept your paint requests and do some custom stuff.

Alternatively, you could hack the CoreGraphics class like this:

bool CoreGraphicsContext::clipRegionIntersects (const Rectangle<int>& r) { saveState(); clipToRectangle (r); bool empty = isClipEmpty(); restoreState(); return ! empty; }

…which is a horribly inefficient way to test for a clip intersection, but is the only way that it’s possible to do it accurately in CoreGraphics.

#5

Hello,

I also had big troubles moving to the new introducer, but I’m so happy I did !

Concerning the empty appConfig.h, you could try to create a new introducer project, and add your files from scratch.
May sound scary, but at least afterward, like a delivery, everything will so cool.

At least, for my own stuff I always had issue like you mention. (appConfig empty, Juce library not found even if the path was properly filled etc… ) until I redid a full introducer project.

hope this help,

Salvator

#6

If anyone has problematic projects that you could actually send me, I’d be happy to take a look at what’s going on - it might just be something simple I can tweak to make them convert properly.

#7

Oh, I’ve realized that I’m somehow incapable of make any sort of product that doesn’t break other people’s systems, no matter how hard I try to be “regular”. :smiley: I get complaints… “Why do you do it that way?” If I didn’t later get compliments from the same people (“It works well and it’s easy to change!”) I’d have given up years ago.

I have quite the little toolchain here, because I have all sorts of generated files - protocol buffer definitions, and things like icons which I translate into C++, so even though it works really smoothly for me, I’m not at all surprised that there are some obscure issues when I try to move! I’m actually synthesizing the .jucer file, even, so I’m not surprised that my jucer file might not be what you expect, even if it works perfectly with the “main branch” introjucer.

Looking at my posts, they definitely come off as whiny :wink: but I would have been really surprised if it did all work. I’m really psyched to get to “modules”, even though I perceive a certain risk to my delivery schedule that leaves me conflicted…

Regarding API changes, CachedComponentImage seems very promising and certainly gives me a path to port my code, so that will solve that problem there - the other changes were tiny, it seems like a few things that returned const String or const StringArray before now return a non-const, it was the work of seconds to fix.

So here’s how I’m going to proceed. I’m in beta-testing for this product, but very few bugs have surfaced. I was developing the move to “Juce modules” on a branch anyway - but I’m going to start a new one, and then document exactly what I do, and the results, so I can give you, Jules, a completely clear test case (or, discover how I fouled up).

And it will also be a clear pattern for people to follow. I think I’m in a minority by developing on the Mac and testing on Windows, but I don’t think I’m alone, so other people will find it helpful.

Stay tuned, it will probably be a few days.

EDIT: It occurs to me that there’s also the issue of the missing XCode settings - to be specific, there were rather a lot of XCode compilation settings I need or want to be on, settings that I couldn’t figure out how to set in the .jucer document (and from reading the Introjucer code, seemed as if impossible to set from the .jucer document!)

It seems to me again that I can’t be the only one wanting these code generation settings and warnings turned on, so either there will be a way to do it in the new system or I can cajole Jules into adding a line in the Jucer to add these missing settings.

This isn’t critical because everything builds even with the default settings - I just get thousands of bogus linkage warnings, and conversely, don’t see a lot of warnings that I want to see (I compile with almost everything turned on, even unsigned and 32 vs. 64…)

#8

FWIW, I don’t get thousands of warnings with the default settings. The latest modules builds clean, both on XCode 4.2 and VC2010.

You also mentioned that you had a ton of git warnings. Are you sure you got a clean clone? I would expect a ton of errors if you tried to pull the modules branch onto the existing master branch, but no errors if you are simply checking out the alternate branch.

No, the Apple LLVM 3.0 defaults are not the most aggressive for C++, but they are geared towards Objective C, which is a more loosely typed language to begin with. There are some areas where the Introjucer->Builds model currently breaks down a little, for example, the extra files one would normally need for a distributed iOS application. But if the thinking is to expand Introjucer into an IDE, a lot of those go away. The command line tools would presumably be invoked, and that gives a much simpler way to expose margin cases to the user.

In the mean time, git can really be your friend. After I run the Introjucer, I run a little git patchup script so that I can keep all my platform specific build tweaks.

#9

So much for “a few days”. Astonishingly, I am waiting on the testers…

Here’s how I start the conversion from the command line in Mac OS/X, 10.6.8:

[code]15:31:59 [hofmann:/development]$ git clone --depth 1 git://juce.git.sourceforge.net/gitroot/juce/juce
Initialized empty Git repository in /development/juce/.git/
remote: Counting objects: 2966, done.
remote: Compressing objects: 100% (2535/2535), done.
remote: Total 2966 (delta 1429), reused 1043 (delta 354)
Receiving objects: 100% (2966/2966), 7.53 MiB | 943 KiB/s, done.
Resolving deltas: 100% (1429/1429), done.

15:33:11 [hofmann:/development] cd juce 15:33:16 [hofmann:/development/juce] git checkout origin/modules
Note: moving to “origin/modules” which isn’t a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 4f0c2c0… More openGL shader fixes. VST fix for Wavelab.

15:33:19 [hofmann:/development/juce]$ ls
amalgamation extras juce_amalgamated.cpp juce_amalgamated.mm
docs juce.h juce_amalgamated.h modules

15:33:56 [hofmann:/development/juce] cd extras/Introjucer/Builds/MacOSX/ 15:34:12 [hofmann:/development/juce/extras/Introjucer/Builds/MacOSX] open The\ Introjucer.xcodeproj
[/code]

At this point, I build and run The Introjucer. It opens with my current project and a default set of modules which seem fine. I save and open in XCode, and I get a lot of errors while compiling.

Instead of attaching the fairly useless compilation errors, I have instead attached the highlights of the… wait, we can’t attach diff files, here, right. :frowning:

Instead, I have the highlights of the diff in a file here, and I have the original .jucer file here, and the result after processing here.

#10

jfitzpat: I only get the git unresolvable conflicts (not even warnings) if I use the git commands given in the JuceQuake posting - if I use the commands I posted above, it’s fine, I get no warnings.

The thousands of compilation warnings are link warnings relating to visibility of elements in common libraries, chiefly STL. All my external libraries seem to be compiled with a different, consistent visibility setting than the default setting given by what, and I haven’t figured out how to change that - but it’s very easy just to change two settings in XCode and all my code is then compiled the same way, except I have to do it every time and I forget, and curse. :smiley: (Or I can turn off those warnings, but ditto…)

And of course I like to turn on all the warnings I can - as high as I can go where I can get no warnings while writing correct code.

There are already “callouts” for platform-specific areas in each development environment. The usecase for adding user-defined values to XCode’s XCBuildConfiguration area is strong, and the amount of code small (I hacked it together myself in the earlier version of Introjucer), so I imagine we can get traction on that…