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.
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 README.md
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.
