CMake 3.12 / Visual Studio - cotire stops custom build rules (Qt moc file creation) from being run

[macdew]

We use qt5_wrap_cpp manually instead of AUTOMOC, and add the resulting moc files to our build target as part of the add_library command: add_library(BLAH_LIB <… sources here, including moc files>)

we then cotire(BLAH_LIB)

This approach used to work well for us, but lately we've seen a lot of machines where cotire fails because it tries to process a moc file before it's been generated - resulting in file not found error.

I'd rather not go back to automoc as we use Qt sparingly and I don't really fancy the overhead of all the file scanning.

As a temporary workaround, it appears to work if I cotire a target without the moc files added, and then add the moc files after using target_sources… But then the moc files don't benefit from precompiled headers.

Is there a way to make the cotire step depend explicitly on the moc target? The problem appears to manifest itself mainly on the MSVC generator - I don't think I've seen reported cases of this with ninja generator.

Qt 5.9.2, CMake 3.12, cotire 1.7.10, VS 2017 (15.7 and 15.8 patch releases)

[macdew]

Ok, it looks like this may be a CMake 3.12 regression... All the machines that are failing are running CMake 3.12, but the ones that still appear to work are all on CMake 3.11.1

I'll try and get some of the failing machines downgraded to CMake 3.11.1 and see if that cures their problem.

[Kaylx]

I can confirm it works for me with 3.11.4 but breaks with 3.12.

[macdew]

We've reproduced using a small stand-alone test project and confirmed that qt5_wrap_cpp + Cotire break on CMake 3.12 but work on 3.11. Moc files do not created sufficiently early (or at all?) with CMake 3.12. I'll consider this a CMake regression and file a report with them.

[macdew]

Apologies for the long delay. We have reported the issue to Kitware as a CMake 3.12 regression - they have investigated and recommended changes to Cotire. The CMake changes in behaviour are intentional.

The bug report and response/recommendations from Kitware can be found here: https://gitlab.kitware.com/cmake/cmake/issues/18353

[petersteneteg]

Also run into this problem. Tried doing what it said on the cmake issue, and commented out line

cotire/CMake/cotire.cmake

Line 3517 in 391bf6b

set_target_properties(${_targetName} PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD TRUE)

And that seems to have fixed it for now. Don't know if this has any other bad side effect?
Looking forward to a official solution!

[martinfalk]

The fix by @petersteneteg has a negative side effect: the pch_pre projects are now always out-of-date in Visual Studio.

[jking777]

I've also run into this problem. Has anyone come up with a better fix than @petersteneteg ?

[jking777]

The fix by @petersteneteg has a negative side effect: the pch_pre projects are now always out-of-date in Visual Studio.

I'm not seeing that behavior. With @petersteneteg fix Visual Studio is building (or not building) projects as I would expect.

Update: OK, now I see the issue. When I do Build Solution the pch_pre projects are built as I expected, but when I do Start Debugging the pch_pre projects are always thought to be out of date and I get prompted to build them. Yeah, that's annoying.

[martinfalk]

@jking777 that was what I was referring to. They are "marked" as out of date, hence VS prompts to rebuild them prior debugging. Selecting build then just runs a check returning that everything is up-to-date for those targets.

[gbottesi]

Here is a workaround : you can put all your generated moc_ files as dependency of a new custom target and make your target dependent of this one:

#moc files
qt5_wrap_cpp(mocs ${my_qt_headers})

# qrc files
qt5_add_resources(src_qrc ${my_qrc_resources})
add_custom_target(QtInternalFilesGeneration DEPENDS ${mocs} ${src_qrc})

...

add_dependencies(MyActualTarget QtInternalFilesGeneration)

[macdew]

Thanks @gbottesi, that workaround appears to be work quite well! No issues rebuilding or debugging my projects.

However, I notice as a side-effect, my .ui / .qrc files are now moved to the Generation project instead of my original project. Do you see the same?

[gbottesi]

True. Hadn't noticed this, but indeed, qrc files have moved project...

[Philippe-Cote-Morneault]

Has there been any fix or any work towards one? This is rather incovenient.

[macdew]

Sadly we resorted to removing Cotire and replacing it with our own pch solution. Whilst not perfect, it gets the job done for us.

Also keep an eye on https://gitlab.kitware.com/cmake/cmake/merge_requests/3553

[Philippe-Cote-Morneault]

@macdew That sucks. From what I understood, we can't use Cotire from CMake 3.12.0 onwards?

[macdew]

@JigsawCorp That's right, we started to see things break when we moved to CMake 3.12.0. As we wanted support for the newer Visual Studio generators and CMake features, we had little choice but to create our own solution. Depending on which compiler(s) you want to support, PCH can be achieved with a few compiler flags only. MSVC is trivial, clang and gcc were a little bit trickier.

We also decided to specify our own precompiled headers for a bit more control (and in the process found some dodgy dependencies and a lot of stuff that could be cleared out). Cotire tended to pull in headers from our own source tree and make the build process more fragile.