Guys, could we have some input here please?
This is something we’d like to support properly in the Projucer, but (without looking into it properly) it feels like the kind of thing that could have lots of subtle ramifications that we need to test first. Everyone’s working full steam on the JUCE 6 release this month so it won’t be done before then, but we will look into it after that. Like Reuben said though, it should be possible to add this to your builds by using the CMake support that is a part of the JUCE 6 release.
thanks for the update.
I don’t want to move to use CMake which is why I’m asking about this. I don’t know CMake and it’s not something that I really want to learn. Projucer does everything I need generally.
Please look into this, we’ve been asking for it for many years, and in all fairness, we’ve been told many times before that this is going to be investigated but it never happens.
I haven’t looked at the JUCE 6 CMake support. Does the Projucer 6 support Cmake export, so I can convert my existing projects to CMake and then tweak some CMake settings? Or do I need to start from scratch, rebuilding my projects in CMake?
I also vote for Pre-compiled header support. My local builds are fine, but on GitHub Actions where you get a 2 core VM, they are painfully slow. 20+ minutes for one plugin.
Also, is there anyway to find what Feature Requests I spent my votes on? I want to move one to this feature, but I can’t find what I spent them on.
There’s no Projucer exporter for the new CMake support, but there are commented examples included in the repo under
examples/CMake, along with an API reference in the
docs folder. The Projucer, DemoRunner and friends also have CMake builds that can be used as examples.
@leehu, I was reluctant towards CMake myself but fwiw I recently tried out @McMartin’s FRUT project which has some really nice tooling/api allowing you to work with CMake in a way that’s similar to the Projucer’s setup. It can even auto-convert your jucer file to a cmake file. Might be worth taking a look if you haven’t already.
Hi, thx. The issue is that I’m knee deep in projects at the moment so I don’t really have time to look into this currently and don’t want to get into the situation where I move over, start having issues and then need to understand CMake in order to solve the problems.
I’m happy with my workflow with Projucer so want to stick with that for now - I think I have some free time scheduled for December
With Juce6 being out for a month or so now to settle, will you guys be looking into this now? thx
We’ve not had a chance yet, but it’s on the to-do list.
thx - upgrading to Juce 6 is contingent on this for me.
We’ve added PCH support to the Projucer Xcode and Visual Studio exporters in d677fd6.
In the build configuration settings for these exporters there is now a “Use Precompiled Header” option (disabled by default) and immediately below is a “Precompiled Header File” file path setting where you can specify an input header file that will be used to generate a
JucePrecompiledHeader_Debug/Release file which is used to generate the PCH file artefact in Xcode and VS. This generated file will be written on project save and placed in the target folder for the exporter (
Builds/VisualStudio201x) so any relative
#includes need to be relative to this. This file will be force included for all source files in your project by default, but you can disable this for specific files with the “Skip PCH” option in the Projucer file explorer:
Since this option is only available for the Xcode and VS exporters, you probably shouldn’t remove the
#includes covered by the force-included PCH from your source files as they will then fail to compile on other platforms/IDEs, but the use of
#pragma once should ensure that the compile time cost for multiple includes is minimal.
Out of interest, have you seen this give much or a reduction in build times?
How does it scale with project size?
awesome - will have chance to try it out on Fri! thanks!
Maybe I’m doing something wrong but on VS2019 I’m able to do the first compilation.
But any future build fails with:
Error C2859 <path_here>\Builds\VisualStudio2019\x64\Debug\Shared Code\project_SharedCode.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header. pajam_SharedCode <path_here> 1
Xcode works as expected from my testing.
Are you able to reproducde the error with a blank JUCE project? I’ve created a new blank GUI project in the Projucer, set the VS2019 exporter debug build config to use PCH, and set the file path to
pch.h which just
#includes <JuceHeader.h>. I’m able to build and re-build the project in VS whilst making changes to the source files without seeing that error. Can you perhaps attach the misbehaving project file?