Pre-processor on unity file fails because it misses include directories from dependencies

[romanc]

Suppose a CMake project with multiple libraries, sometimes depending on each other, and multiple executable linking to these libraries. To be concrete, suppose libA depending on libD. The CMakeLists.txt of libA reflects this relationship by having the line taget_link_libraries(libA libD) and I run cotire on both, libA and libD, separately.

Now, if libA is processed before libD, then libD is not yet a TARGET for CMake, because add_library(libD ...) was not yet called, when cotire(libA) is called. In that case, when running

function (cotire_get_target_usage_requirements _target _config _targetRequirementsVar)

for libA,

get_target_property(_librariesToProcess ${_target} LINK_LIBRARIES)

will add libD to _librariesToProcess, but in the subsequent while-loop, if( TARGET ${_library} ) will return false for libD, because CMake does not yet know the libD as a TARGET. The dependency libD is therefore discarded and not added to _targetRequirements. Is there any way to work around this problem?

The problem started from here: I cotired libA without unity build. This runs through, but it emits a warning like

-- 1 line(s) skipped, see /path/to/build/.../cotire/libA_CXX_unity_prefix.cxx.log

and looking at the log file it would say

In file included from /somewhere/in/libA/file.cpp
fatal error: [some/header/from/libD.h]: No such file or directory
compilation terminated.

So, it correctly create the unity source for libA, but then fails while running the pre-processor on these cpp files to get a list of all headers. And the pre-processor fails because it misses the include directories to libD, because libD was dropped as dependency as described above.

[dethtoll1]

We've hit this same issue, and would be very interested in any ideas to fix it!

We've noticed that this issue only occurs on Linux. We don't see this problem on Windows.

In a nutshell, cotire will not correctly inherit dependencies if you follow this pattern:

# High level
add_library(HighLevel ...)
target_link_libraries(HighLevel LowLevel)

# Cotire High level
set_target_properties(HighLevel PROPERTIES COTIRE_CXX_PREFIX_HEADER_INIT HighLevel.pch)
cotire(HighLevel)

# Low level
add_library(LowLevel ...)
target_compile_definitions(LowLevel PUBLIC FOO)

That make look strange, but the ability to define high level libraries before low level libraries is a fundamental feature in CMake for large codebases (with CMake targets defined throughout a multitude of subdirectories)

It will work if you perform cotire last:

# High level
add_library(HighLevel ...)
target_link_libraries(HighLevel LowLevel)

# Low level
add_library(LowLevel ...)
target_compile_definitions(LowLevel PUBLIC FOO)

# Cotire High level
set_target_properties(HighLevel PROPERTIES COTIRE_CXX_PREFIX_HEADER_INIT HighLevel.pch)
cotire(HighLevel)

The problem is that this doesn't work when multiple directories are involved. Ideally we'd run cotire at the end of our processing (i.e. at the end of our root CMakeLists.txt file). However, calling cotire doesn't seem to work unless it's run from the same directory as the target.

I haven't found any creative solutions to get around this that wouldn't require restructuring our codebase (which would be really unfortunate).

[gblikas]

@dethtoll1 I am experiencing the same issue, but on Windows. Here is some of my VS installation information:

[
  {
    "instanceId": "2dae49ae",
    "installDate": "2018-07-12T20:38:51Z",
    "installationName": "VisualStudio/15.9.4+28307.222",
    "installationPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community",
    "installationVersion": "15.9.28307.222",
    "productId": "Microsoft.VisualStudio.Product.Community",
    "productPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\Common7\\IDE\\devenv.exe",
    "isPrerelease": false,
    "displayName": "Visual Studio Community 2017",
    "description": "Free, fully-featured IDE for students, open-source and individual developers",
    "channelId": "VisualStudio.15.Release",
    "channelUri": "https://aka.ms/vs/15/release/channel",
    "enginePath": "C:\\program files (x86)\\microsoft visual studio\\installer\\resources\\app\\ServiceHub\\Services\\Microsoft.VisualStudio.Setup.Service",
    "releaseNotes": "https://go.microsoft.com/fwlink/?LinkId=660692#15.9.4",
    "thirdPartyNotices": "https://go.microsoft.com/fwlink/?LinkId=660708",
    "updateDate": "2018-12-28T22:26:39.937551Z",
    "catalog": {
      "buildBranch": "d15.9",
      "buildVersion": "15.9.28307.222",
      "id": "VisualStudio/15.9.4+28307.222",
      "localBuild": "build-lab",
      "manifestName": "VisualStudio",
      "manifestType": "installer",
      "productDisplayVersion": "15.9.4",
      "productLine": "Dev15",
      "productLineVersion": "2017",
      "productMilestone": "RTW",
      "productMilestoneIsPreRelease": "False",
      "productName": "Visual Studio",
      "productPatchVersion": "4",
      "productPreReleaseMilestoneSuffix": "1.0",
      "productRelease": "RTW",
      "productSemanticVersion": "15.9.4+28307.222",
      "requiredEngineVersion": "1.18.1042.9589"
    },
    "properties": {
      "campaignId": "369401847.1529645426",
      "channelManifestId": "VisualStudio.15.Release/15.9.4+28307.222",
      "nickname": "2",
      "setupEngineFilePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\Installer\\vs_installershell.exe"
    }
  }
]

Additionally, out of the box, it seems like because I am using sub-dependencies, I do not get a actual pch target.

[TaaTT4]

I'm in the same situation. Did anyone find a workaround for this issue?