Killer feature: edit build settings on the platform's IDE?


#1

The basic issue

I need to have values for buildSettings in my XCode project that are fairly different from the default set provided by the Introjucer.

The settings I need to turn on are disjoint from the ones automatically provided by the Introjucer - I simply need to add more settings, not override the Introjucer’s.

Most of these are GCC settings which you can fudge through the Introjucer’s GCC flags - but some can’t be done that way.

Right now, I have simply and brutally edited jucer_ProjectExport_XCode.h to hardcode in my settings - how much easier open source makes my life! - and this isn’t a terrible solution for me but I can imagine that a lot of people might have this issue.

We have a similiar issue in Windows

I haven’t really looked at that, someone else does the Windows builds, but the same workflow issue happens - we want to make changes in the generated Visual Studio file and “backporting” these changes to the .jucer file is either difficult or impossible.

My dream feature

This isn’t too impossible a dream - it’s that you could “import changes” into the Jucer from a file that was once the output of the current .jucer project.

So I’d create an Introjucer, generate projects in XCode or Visual Studio or…, open these projects and make changes, and then bring at least some of these changes back into the introjucer!

I looked at how to do this with XCode, and it frankly didn’t look too bad at all. Reading the XML file is no big deal, and an awful lot could be done simply by doing a comparison between “buildSettings” list before and after, and adding a “buildSettings delta” to the Juce project, and that’s very little code.

The next major class of changes you’d want to be able to import would be adding and removing files. That’s perhaps a little more code, because you need to deal with adding and removing source code and frameworks.

The nice part is that once you have the import functionality, you can roll this out incrementally and it’d still be really useful - even just the buildSettings solves a general problem I’m sure a lot of developers have.


#2

Yep, it’s certainly possible to pull specific settings out of the project files… But so much typing! I totally agree though, and have pondered this myself.


#3

Both XCode and Visual Studio have support for “property sheets” and “shared property settings”, it is possible to have files designating project and target settings that span multiple projects. We should be using those.

If you look at my xcodeproj and visual studio workspace for DSP Filters, you can see that I am using these shared settings (DSP Filters is three projects in one, and for XCode there are multiple targets within a single project).

In my opinion, this is the correct approach - a single project file which builds for all the platforms. Note that even under Windows it is possible for one project to target both Windows and Android platforms (if you have the appropriate support files installed).

Through clever arrangement of directories, it would be possible for Juce to provide both XCode and a Visual Studio 2010 project files which not only have their own shared property sheets but also allow you to have your own property sheets that override the default settings. This means that you could set your properties once, across all your projects (or a subset of them) without having to change the Juce project files. Jules could also change build settings in a way that if you have overriden the default behavior, your settings would be preserved.

It is on my to-do list to bring this functionality to the DSP Filters projects, once that is done anyone can just copy the settings and project files, empty them out, and replace it with their own stuff, and get this behavior.


#4

Typing!? I hard-coded it into JUCE :smiley: and it wasn’t much typing, just cut and paste and a 10-second emacs keyboard macro!

(By the way, if you don’t use some editor like emacs that lets you say something nice, “And now repeat what I just did for every line in this region” then it’s really worth your time to find and adopt one. This saves me at least an hour a week…)

TheVinn has it - using property sheets is the way to go. Huge win and very little work for you, Jules. Seems to me that you only need add a new slot for the property sheets for each platform and then you’re done…?

jucer_ProjectExport_XCode.h: 483

        // Juce needs Arraysize.h!  
        // See url=https://github.com/rec/swirly-avr/blob/master/src/swirly/base/ArraySize.h!
        static const char* EXTRAS[] = {
          "DEAD_CODE_STRIPPING = YES",
          "GCC_AUTO_VECTORIZATION = YES",
          "GCC_DEBUGGING_SYMBOLS = full",
          "GCC_DYNAMIC_NO_PIC = YES",
          "GCC_ENABLE_FIX_AND_CONTINUE = YES",
          "GCC_ENABLE_SSE3_EXTENSIONS = YES",
          "GCC_ENABLE_SSE41_EXTENSIONS = YES",
          "GCC_ENABLE_SSE42_EXTENSIONS = YES",
          "GCC_ENABLE_SUPPLEMENTAL_SSE3_INSTRUCTIONS = YES",
          "GCC_FAST_MATH = YES",
          "GCC_INCREASE_PRECOMPILED_HEADER_SHARING = YES",
          "GCC_INLINES_ARE_PRIVATE_EXTERN = NO",
          "GCC_OPTIMIZATION_LEVEL = 0",
          "GCC_SYMBOLS_PRIVATE_EXTERN = NO",
          "GCC_UNROLL_LOOPS = YES",
          "GCC_WARN_64_TO_32_BIT_CONVERSION = YES",
          "GCC_WARN_ABOUT_MISSING_FIELD_INITIALIZERS = YES",
          "GCC_WARN_ABOUT_MISSING_NEWLINE = YES",
          "GCC_WARN_ABOUT_MISSING_PROTOTYPES = YES",
          "GCC_WARN_EFFECTIVE_CPLUSPLUS_VIOLATIONS = NO",
          "GCC_WARN_FOUR_CHARACTER_CONSTANTS = YES",
          "GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS = NO",
          "GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED = YES",
          "GCC_WARN_PROTOTYPE_CONVERSION = YES",
          "GCC_WARN_SHADOW = NO",
          "GCC_WARN_SIGN_COMPARE = YES",
          "GCC_WARN_STRICT_SELECTOR_MATCH = YES",
          "GCC_WARN_UNDECLARED_SELECTOR = YES",
          "GCC_WARN_UNINITIALIZED_AUTOS = NO",
          "GCC_WARN_UNKNOWN_PRAGMAS = YES",
          "GCC_WARN_UNUSED_FUNCTION = YES",
          "GCC_WARN_UNUSED_LABEL = YES",
          "STANDARD_C_PLUS_PLUS_LIBRARY_TYPE = static",
          NULL};

        for (const char** str = EXTRAS; *str; ++str)  
          s.add(*str);

#5

Ah, I meant typing involved in parsing the old project file to extract the settings that had changed. Yes, property sheets are certainly a good idea for this.

BTW Tom - you said “juce needs ArraySize.h”… There’s a numElementsInArray() function that should do the trick for you :slight_smile: