Projucer individual file compiler settings feature request


For our project, we are building certain source files with different compiler settings. For example, we would enable different vector extensions (SSE4, AVX, AVX2, AVX512) for different files and dispatch at runtime. In some cases, we also would like to build certain files with a different specialized compiler, like ICC, ISPC, Rust, etc.

This does not seem to be supported by the current version of Projucer. So I would like to propose a feature that adds this useful extra flexibility.

The following describes a possible realization in Projucer.

In the File Explorer folder view, an extra selector for a ‘build setting’ is added for each file that is going to be compiled. The build settings are named and can be added globally, possibly from this view with a plus-button near the file list.

The build settings are defined in the individual exporter modules. A new property editor appears for each build setting, allowing to select different build styles. The possible selections are “build with extra flags” or “build with non-standard compiler”, followed by a text box for the specifics. Certain environment variables could be made available for the strings entered there to make it easy to refer to the default compiler and default Projucer build flags, etc.

I think all target project formats supported allow for custom build rules and per-file flags, so the support of the exporter should be relatively straightforward.

Please let me know if I have overlooked something obvious!


We’ve had requests for per-file compiler flags before so it’s in our backlog, but I can’t make any promises on timeline as it’s quite low priority.


Thank you, ed95. It’s the one feature that keeps us from using Projucer and making our life a lot harder. I find per-file settings and inclusion of 3rd party (resource) compilers or build hooks very essential. Maybe you can reevaluate the priority? I don’t think “quite low” is adequate.

How are the chances a corresponding pull-request would be included in the master branch? If they are reasonable, I would do the implementation myself.


I agree that it would be a useful feature, but it would require a considerable amount of work both on the IDE integration and UI changes and unfortunately we don’t have that time to spare at the moment. We’d certainly take a look at a PR for this, and if it passes internal code reviews it’ll get merged in, so if you urgently need this feature then that would be the quickest way to get it in.


I’ve submitted a pull request (#455 commit 33197cea1f567fcdaab2fe98a7644603b1165177) that implements the per-file compiler flag feature for all exporters.

A new combo box is added for all files listed in the file browser that are selected for compilation. In the combo box, you can create or select a compiler flag setting. Note that in the file browser you only set the setting name. The actual compiler flags are set in the exporter properties.

Once you have created a setting, the property sheet for the exporter will list it directly under “Extra Compiler Flags” with the title “Extra Compiler Flags for YourSetting”. You can list the flags for the exporter there and they will be included for just those files that have the corresponding setting selected.

I’d be happy to receive feedback or suggestions for further improvements and enhancements.

[Request] Per File Warning Suppression

That was quick! Thanks, I’ll take a look.


Sorry for being slightly off topic

is this just because it’s something that is sitting in your backlog that you intended to implement?
I ask because it’s directly in contravention of the

We don’t accept third party GitHub pull requests directly due to copyright restrictions

I was considering to add “build numbers” as a feature of Projucer (with a --bump-build-number command line flag) as well as a “beta flag”, both things that should be fairly simple to implement and probably useful to the community at large. Another thing was adding in newer DAW versions to the PluginHostType class, something that is almost certainly at the bottom of your pile of “important things to do” list (again would be useful to the community I would imagine).


Perhaps I should have worded my reply above a bit better, by “passing internal code reviews” I mean that generally we will re-write pretty much all of the code to fit in with the JUCE coding guidelines, style, and (especially for something like a Projucer PR) fitting the code in nicely with the rest of the large project structure. The readme in the repo states that we won’t accept third party GitHub PRS directly, which is true. For something like this though it’s useful as a starting point for a feature and will help to bump it up the priority list if someone has already made a start at implementing it.


Thanks for the clarification :slight_smile: