Firstly I’d like to say thanks Jules, the solid work over the past couple of days have really made the Introjucer into an incredible tool, very little post generation fiddling now! I would like to add two wish list items, these are fairly low priority and more for future thinking than immediate requests.
Named binary resources
At the moment all resources get added to the same BinaryData file. While this is fine for small projects I like keeping all resources (audio samples etc.) saved as binary resources as it makes it so much simpler for the user, requires no installers and is easier to manage cross platform. The problem is when the text files get very large (> 20MB) it takes forever to compile. It would be nice to replace the “Add to binary resources” button with a drop down of binary names you could set. This would also make code look better as you could group types of resources: graphics, audio, settings etc.
File templates
I’m pretty sure this kind of thing will be coming with the new Jucer (Introjucer development?) but it would be handy to be able to specify templates when creating new files. I imagine this to be an extra menu item below “Add New CPP & Header File” where the user could create files (e.g. class template with leak detector etc.) and the name of the file would be used as the class name. I’m sure you’ve thought about this much more thoroughly than me but would be useful.
@salvator - I’ve added a couple of the flags you mentioned, but I’ve also added a “custom xcode flags” setting, that should let you put any other custom settings directly into the project without needing to hack the introjucer… Let me know if these new tweaks do the job for you!
Here’s the line I’m adding to the new Introjucer Xcode flags (if it can serve anyone else interested with building plugins) :
ARCHS = “ppc i386 x86_64”
,VALID_ARCHS=“ppc i386 x86_64”
,MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.6
,MACOSX_DEPLOYMENT_TARGET_i386 = 10.5
,SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.6.sdk
,SDKROOT_ppc = /Developer/SDKs/MacOSX10.5.sdk
,GCC_VERSION_ppc = 4.0
With this, I’m able to build big 32/64 + ppc plugins, straight out of IntroJucer, without compile errors (*).
(*) There’s still 1 compile error in juce_VST_Wrapper.mm when using the stock tip.
This can be resolved by adding the following after “#if JucePlugin_Build_VST”.
#if __LP64__
#undef JUCE_SUPPORT_CARBON
#define JUCE_SUPPORT_CARBON 0
#endif
Now Jules do you know if it’s possible to add existing OSX frameworks to a project thru theses flags ?
Here’s a feature, Jules get on this if it doesn’t already exist.
Define an open standard that uses XML to describe the files, directories, and virtual folders (i.e. custom user defined groups of files) that make up the project. Allow these “project” XML files to have inheritable property sheets which are also XML files, that have some platform independent settings (i.e. preprocessor defines, include directories) and also some environment dependent settings (e.g. MSVC-specific things such as “UAC”).
Make sure this open standard is defined in such a way as to keep separate in separate XML files the specification of files used in the build versus the compile / environment options. This way a single XML chunk can reflect the files and directories used to build a particular project in an environment-agnostic fashion.
Use this format in Introjucer, then convince the majors to adopt this format (Microsoft, Apple, et. al.). At the conclusion of this feature we should have the equivalent of “OpenDocument” for building a software project.
[quote=“TheVinn”]Here’s a feature, Jules get on this if it doesn’t already exist.
Define an open standard that uses XML to describe the files, directories, and virtual folders (i.e. custom user defined groups of files) that make up the project. Allow these “project” XML files to have inheritable property sheets which are also XML files, that have some platform independent settings (i.e. preprocessor defines, include directories) and also some environment dependent settings (e.g. MSVC-specific things such as “UAC”).
Make sure this open standard is defined in such a way as to keep separate in separate XML files the specification of files used in the build versus the compile / environment options. This way a single XML chunk can reflect the files and directories used to build a particular project in an environment-agnostic fashion.
Use this format in Introjucer, then convince the majors to adopt this format (Microsoft, Apple, et. al.). At the conclusion of this feature we should have the equivalent of “OpenDocument” for building a software project.[/quote]
Sounds like pretty much exactly how it already works! (ok, apart from inheritable properties, but that’d be trivial to add)
Yeah but you forgot about the part where you get it formalized, turned into a standard (OASIS?), and adopted by all vendors’ IDEs: Visual Studio, XCode, Eclipse, IntelliJ, etc…
Implement import of Visual Studio 2010 projects (if its not already done). Make sure this can be done with a command-line invocation so IntroJucer could at least be part of a Windows toolchain (gag)
Support background monitoring of an open Visual Studio 2010 project file. IntroJucer will lurk in the background like a stalker and wait for the project file to change. When this happens, it will re-import the Visual Studio 2010 project (while preserving all IntroJucer-specific settings). The re-import should detect changes to the project’s groups and project settings.
Provide options for having the background operation of IntroJucer to perform automatic export of Macintosh projects or GNU/Linux Makefiles when the Visual Studio project changes.
This would actually get me to use IntroJucer. Because it would not change my workflow. I would change build settings in Visual Studio, rename files in Visual Studio, add/remove source files in Visual Studio (see a pattern here?). Everything would happen in Visual Studio. But when it comes time to commit my changes, oh look IntroJucer has been my faithful lap-dog and automatically maintained the corresponding .xcodeproj and Makefile for me!
On the Macintosh side of things, having command line runnable IntroJucer (if not already done) would let me write a nice handy shell script that would pull the HEAD of my project, rebuild the Macintosh .xcodeproj, and perform an automated build.
The take-away point is that IntroJucer would be integrated in a way where I don’t have to learn a new GUI. I sacrifice none of the native features of my development environment. And, it’s not FORCED on me (I could always build projects the long way). Plus, I keep my favorite IDE workflow intact.
Would it be possible to add an option to the XCode exporter, so that XCode builds universal Intel binaries with 32 and 64 bit binaries inside (fat binaries?) as discussed here: http://www.rawmaterialsoftware.com/viewtopic.php?f=4&t=8787
It does i was confused cause XCode shows that as “Release | i386” and there is a second options “Release | x86_64” and i thought there are two seperate configurations. But i just did a JuceDemo build with that option and i shows
