Introjucer project settings: feature requests, please!

People have made a lot of small requests recently for introjucer settings that they’d find useful in generating their projects. Unfortunately, I’ve lost track of most of these, so wanted to create a thread to collect together all the most popular requests, which I’ll then sit down and spend a day bashing them all out…

Not too much discussion on this thread, please! Just quickly jot down any features you’d like to see, and I’ll collate the ideas afterwards.

To get things rolling, here are a few items that I already had on my list:

  • MSVC: add post-build event
  • MSVC: specify libs to link to
  • MSVC: library search path
  • MSVC: control over manifest inclusion
  • xcode: plist customisation
  • xcode: excluded file list
  • android: better way to control manifest XML options (ideas welcome here for the best approach)

Thanks!

MSVC better app icon
currently only the 32x32 is added to the icon-file (on windows), you can also add a additional 256x256 png (since Vista) into the container-file

compiling inside introjucer
http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=7953

MSVC costum build events
http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=7774&hilit=icon&start=15#p44483

MSVC x64 Platform :!: :!: :!:
Most important: x64 Platform should be automatically generated
http://www.rawmaterialsoftware.com/viewtopic.php?f=3&t=7627

Flexibilty
Project-Exportes can have different settings (customizable in the GUI)

[quote=“chkn”]Flexibilty
Project-Exportes can have different settings (customizable in the GUI)[/quote]

Sorry, don’t understand what you mean there…?

sorry was not clear, i mean that all settings, which are global for the project, will inherit to the project-exportes, and you can change several parameters for every project export separately.
For example: I have one Project-Export that uses DirectWrite, another not.
You can already do this, because of the #ifdef-change in the appconfig, but it would be nice to do this directly with the check-boxes inside introjucer.
But this is currently not so important for me, but nice to have.

Xcode : Ability to add frameworks

Hi Jules,

I’ve tested the modules version and it’s great. I’ve seen that with each project the modules source code is copied into the project’s folder and that’s fine, but I’d like to suggest to include also an option in Introjucer to use the modules source code directly from its base folder instead of copy them, just a way to share the modules source code between several projects.

Thanks

This is a great idea - we can help Jules prioritize his requests this way.

I don’t really have any requests that aren’t here, I don’t think?

+1 for xcode: plist customisation
+1 for bigger icons for Vista et. al. I hadn’t realized that!

[quote=“Xavi”]Hi Jules,

I’ve tested the modules version and it’s great. I’ve seen that with each project the modules source code is copied into the project’s folder and that’s fine, but I’d like to suggest to include also an option in Introjucer to use the modules source code directly from its base folder instead of copy them, just a way to share the modules source code between several projects.

Thanks[/quote]

That’s already in there - when you select each module in your project settings, it has an option to control whether it gets copied or not.

Android is a big subject on it’s own. To deploy on Android I didn’t just modify the AndroidManifest, I had to touch quite a few lib files as well. I basically put the bundle name in the project properties, then reworked the JNI helper macros. I still had to touch the two native Java files, etc., all so that the app would have a unique identifier instead of the generic com.juce.

For iOS/XCode: The ability to include extra files in the bundle (Default.png, Entitlements.plist).

Icon fix (currently generates icon file, which iOS doesn’t use).

General: The ability to specify icons by platform. The general icon works OK (well, not on iOS), but we generally have variations that are tweaked for each platform.

A lot of the other suggestions are good, but I don’t have any priority preference.

File tree openess state save.

File tree openess state save.

Particularly egregious :stuck_out_tongue: since Juce supports saving file tree openness in just a couple of lines of code - I make use of that in my own code.

Could you disable this by default or/and add an option to toggle the copy option for all modules at once.

If the local juce copy is in a subversion repository all the .svn subfolders get copied too, which takes some time and also stalls the Introjuce meanwhile. So if you forget to uncheck the copy option for all modules you will have to wait some time, in my case only to delete the .svn directories afterwards.

Chris

[quote]Could you disable this by default or/and add an option to toggle the copy option for all modules at once.

If the local juce copy is in a subversion repository all the .svn subfolders get copied too, which takes some time and also stalls the Introjuce meanwhile. So if you forget to uncheck the copy option for all modules you will have to wait some time, in my case only to delete the .svn directories afterwards.[/quote]

Yes, I’ll have to do something like that.

Ah, SVN… the devil’s own source-control system. I’d forgotten that the folders may be infected with all those horrific hidden files - perhaps if you do choose to copy a module, it should avoid copying any hidden files?

I thought about that too, but on the other hand maybe someone might want to copy the repository along with the modules to be able to test changes in a separate enviroment.

Chris

  • specify library path for all exporter (not just MSVC) Under gcc, it’s the option “-L”

  • Import an existing project (for example from VS / Xcode) to figure out the used options and reflect in the IntroJucer project file. I consider Makefile to be unparseable.

  • A component graphical editor like the Jucer (but with some options like “use pointers or direct objects for component members” etc…)

  • +1 for being able to run the compiler/linker directly in Introjucer.

  • Remove the Visual Studio 6.0 exporter since the current code doesn’t compile anymore in VS6

Import an existing project (for example from VS / Xcode) to figure out the used options and reflect in the IntroJucer project file. I consider Makefile to be unparseable.

This is the Holy Grail of this sort of system and is clearly impossible in general. However, it might at least be possible to import some settings from project files.

About a third of the suggestions in this thread are some variation of this one - “I need the following settings in this IDE.”

+1 for being able to run the compiler/linker directly in Introjucer.

Don’t you want to run the compiler in some place where you can fix your compilation errors? Nearly always, those errors will be in your C++ files, and you want to fix them in some C++ code editor - which is not the Introjucer’s job.

I actually do the reverse - I simply never use the Introjucer’s GUI. In the old Introjucer, at least, you can run it from the command line - and XCode can be called from the command line (not sure about Visual Studio) - so my toolchain consists of a program that builds a .jucer file from my file tree, a call to the Introjucer, and a call to XCode, all of which runs in a window in emacs (where I do all my editing).

[quote=“jules”][quote=“Xavi”]Hi Jules,

I’ve tested the modules version and it’s great. I’ve seen that with each project the modules source code is copied into the project’s folder and that’s fine, but I’d like to suggest to include also an option in Introjucer to use the modules source code directly from its base folder instead of copy them, just a way to share the modules source code between several projects.

Thanks[/quote]

That’s already in there - when you select each module in your project settings, it has an option to control whether it gets copied or not.[/quote]

Ah!, I didn’t see it…
One last thing, it’d be useful to include a note in the module updater showing the versions of Introjucer, Jucer, etc, just to know if it’s necessary to recompile them or not.

Hello,

I always have to edit the introducer in order to make it generate plugins “ready to compile in all formats” (i.e. remove carbon files for 64 bits, set proper SDK, add ppc as valid arch etc…)

Maybe you could get some inspiration about the following?
in jucer_ProjectExport_XCode.h, I add the 7 last lines :

[code]if (! iOS)
{
const String sdk (config.getMacSDKVersion().toString());
const String sdkCompat (config.getMacCompatibilityVersion().toString());

        if (sdk == Project::BuildConfiguration::osxVersion10_4)
        {
            s.add ("SDKROOT = macosx10.4");
            gccVersion = "4.0";
        }
        else if (sdk == Project::BuildConfiguration::osxVersion10_5)
        {
            s.add ("SDKROOT = macosx10.5");
        }
        else if (sdk == Project::BuildConfiguration::osxVersion10_6)
        {
            s.add ("SDKROOT = macosx10.6");
        }

        if (sdkCompat == Project::BuildConfiguration::osxVersion10_4)       s.add ("MACOSX_DEPLOYMENT_TARGET = 10.4");
        else if (sdkCompat == Project::BuildConfiguration::osxVersion10_5)  s.add ("MACOSX_DEPLOYMENT_TARGET = 10.5");
        else if (sdkCompat == Project::BuildConfiguration::osxVersion10_6)  s.add ("MACOSX_DEPLOYMENT_TARGET = 10.6");

        s.add ("MACOSX_DEPLOYMENT_TARGET_ppc = 10.4");
        
        
        s.add ("MACOSX_DEPLOYMENT_TARGET_i386 = 10.5");//NEW
        s.add ("MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.6");//NEW
        s.add ("SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.6.sdk");//NEW
        s.add ("ARCHS = \"ppc i386 x86_64\"");//NEW
        s.add ("EXCLUDED_SOURCE_FILE_NAMES = \"$(EXCLUDED_SOURCE_FILE_NAMES_$(CURRENT_ARCH))\"");//NEW
        s.add ("EXCLUDED_SOURCE_FILE_NAMES_x86_64 = \"\*Carbon\*.cpp\"");//NEW
        s.add ("VALID_ARCHS = \"ppc i386 x86_64\"");//NEW  

    }[/code]

With this, I do not need to manually touch the Xcode build settings anymore. Food for thoughts.
BTW : If you could also add 10.7 (SDK & deployment target) it would also be cool.

Salvator

That’s interesting stuff, but I’m not sure how I can add those settings without breaking a lot of other people’s code… By hard-coding the architectures and deployment targets like that, it’ll override the other settings that are being set in the introjucer. Perhaps it could be done so that these settings get used only if the user has selected 10.4 as the SDK target…?