Beginner question about Juce workflow

Hi, newbie here. I’m developing a stand-alone app intended for iOS and Android, perhaps desktop.

Just wanted to confirm that I understand the workflow correctly.

  1. Do I need to do all development in Projucer? Can’t I just pick which modules that I need, export it to, say, X-Code, and finish development there?

  2. What if I need to add a module after doing so? Is it possible to go back and add one after working with the project in X-Code (without going through some type of merge-hacking)?

The intended workflow with Projucer traditionally was just that : set up the project in Projucer and export to Visual Studio/Xcode etc. That has recently changed a bit since there’s also the Projucer live build feature available. However, for any large scale development you will want to export to a real IDE anyway.

You can add modules and change other settings in the Projucer project later and export again to your IDE, but it does appear some changes manually made in the IDE settings may get removed when doing that.

1 Like

Thanks Xenakios. I’m sure it’s possible to add modules to an existing project but don’t know how cumbersome it will be. Sometimes such an endeavor is more trouble than it’s worth.

Just as an idea, what about adding all modules, then commenting them out in the appropriate includes? Sure, the source code repo will be bloated. Just spitballing to avoid troubles down the road, in case other modules are needed on an existing project.

Yes, I’d greatly prefer to work in X-Code or another IDE, if possible, for a non-trivial project.

Adding modules later is not that cumbersome if you don’t need to be changing the IDE settings manually all the time. And if you have some IDE settings that you can’t currently set in the Projucer project, you can suggest the JUCE team to add it into Projucer, they might even do that.

Is there something unclear about which JUCE modules you might want to be using in your project? The default ones Projucer adds are fairly good for all kinds of development.

Not specifically, I’m still new. But IDE settings such as anything in xcodeproj or xcworkspace will definitely change. Could be a PITA in that case, sounds like. I should just try it.

That’s why I was wondering about just adding all the modules initially, even if I don’t plan on using OpenGL for instance, at least have it there commented out. If done right the binary will be the same, even with the module in the project’s code repository.

Actually the Projucer covers most of them…

If I have trouble, I usually try to find the setting in my IDE to make it compile/run and before doing anything else, I search for the switch that fixed it in the Projucer, re-save my projects and carry on.

If you find a setting in the IDE, that is not covered in Projucer, shout at the forum, either somebody knows a workaround, or it will be added…

1 Like

Well, taking X-Code as an example, they have their XML formatted project files, which Projucer is creating. Once the project is “up and running” in X-Code, it’s inevitable that there will be X-Code specific controls that will modify the project files in a way that Projucer won’t be able to handle or perform.

There aren’t that many modules so I’m just leaning towards adding them all, and trying to comment them out manually in the appropriate include. Just at first glance, looks like this would be in “Juce Library Code/JuceHeader.h”. One line comment and should be 100% handled! I’ll test this out of course.

I’m also leaning towards “copy the modules to the project” so the project can be properly checked in to version control. Projucer is pretty slick, and it’s amazing that it’s cross platform, so they designed it with this specific workflow. The copying of modules to the project seems like a minor work-around. (Normally you’d have some mechanism for external dependencies like cocoapods, and you wouldn’t check those into version control).

So my plan isn’t ideal but seems fairly easy to work around if needed. For instance, if there’s a new module or an updated module, I’ll just export a hello world and extract the dependency manually and add it to the already-in-motion X-Code project.

If there’s a better way, please LMK. Thanks.

It is your right to doubt that, and I know, there are many users on the forum, that go that route. That’s perfectly fine.

For me it worked up to now, I link 3rd party libraries, I use different C++xx styles, I change header sizes to fix 3rd party wrapping software…

It is really your choice, but I would encourage you, if you hit settings that you don’t find in Projucer, just ask…

Good luck with your projects.

That’s the part that I don’t understand. Projucer doesn’t have all of the controls that X-Code does, so I’m not clear on what you’re trying to say?

What I’m saying is:

  1. Create a project in Projucer
  2. Export to X-Code
  3. Do typical big-project things like adding dependencies or similar changes that will affect X-Code project files in a way that Projucer cant. (e.g. you can’t add cocoapods to Projucer).
  4. Now I cannot go back and edit the project in Projucer because it will overwrite any customizations to the project that I’ve made in X-Code.

Not sure if we’re on the same page? You’re linking 3rd party code, different styles, but are you actually going back and changing your modules around in Projucer after you’ve done your changes in the external IDE? My understanding is that this isn’t possible?

Yeah, it’s not an issue of doubt at all. X-Code or other ide’s absolutely will 100% have controls related to the project files that won’t be in Projucer. It’s not like Projucer has re-created all of the project-related functionality of every IDE, so I don’t understand your point.

The issue is about possible workflows. Once the project is exported to, say, X-Code, and after proprietary changes are made to the X-Code projects (more dependencies added such as cocoapods, etc), then any attempt to re-export from Projucer will break this, correct?

Yes. Calling re-save projects overwrites your settings. But as I said, for most of the settings, there are command line options, that you can set in Projucer, so that re-saving would create the same project again. That’s my workflow at least, that doesn’t mean it works for everybody though…

Yes, that is correct.

I am not familiar with cocoapods, but my short reading tells me this might be indeed a problem. Seems cocoapods serves the same purpose like Projucer, which is to set up projects? In this case this contradicts it. So yes, in that case I guess you might have no chance to roundtrip to make chances from Projucer later…

But maybe somebody else on the forum who used cocoapods knows a way?
I just encouraged to ask, I didn’t claim to have a solution to everything :wink:

BTW: just searched a bit for cocoapods in the forum, maybe this helps?

Cocoapods is just a package manager. So for instance if you want to integrate Facebook, you’d add the facebook iOS SDK using a cocoapods settings file. You don’t actually check in the actual dependency into your version control project, instead another developer can clone the code/project and simply do a “pod install” which pulls the appropriate dependencies as specified in your cocoapods file.

It just seems that I’d want to use projucer to set up the project structure, export it and never look back. I could be wrong. But IDK why I’d need to go back if I’ve already exported every module (and just commented them out in the appropriate .h file).

Sorry if this sounds wrong, but it seems like a reasonable workflow. IDK why I’d need or want to go back to projucer except to get the latest versions of dependencies which I can likely do by exporting a hello world with the new dependencies, doing a diff on the appropriate source code files and applying them to my in-motion X-Code project.

That sounds perfectly reasonable for me. The only thing that bothers me, if there are changes in the modules, re-saving might be a way to save hazzle, so it would be good to leave that route open…

But maybe it is a possibility to create an exporter, that exports a Projucer project into a cocoapods module? Just a thought…