Build failure with --Xcode after llvm stable/20221013 rebranch?

Development Compiler
, ,
1

Recently running utils/build-script --swift-darwin-supported-archs "$(uname -m)" --xcode is failing for me with the following error:

CMake Error at cmake/modules/SwiftSharedCMakeConfig.cmake:16 (find_package):
  Could not find a package configuration file provided by "LLVM" with any of
  the following names:

    LLVMConfig.cmake
    llvm-config.cmake

  Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
  "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  cmake/modules/SwiftSharedCMakeConfig.cmake:253 (swift_common_standalone_build_config_llvm)
  CMakeLists.txt:746 (swift_common_standalone_build_config)

I believe this is after the rebranch of llvm to stable/20221013 and comparing it with stable/20220421 I found this commit [CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are… · apple/llvm-project@3a1c81e · GitHub which seems to modify the expected output paths for llvm artifacts, which could be the reason of the cannot find the llvm config files error.

Was able to make the command by locally reverting few bits of this commit to the old paths. Mainly this one https://github.com/apple/llvm-project/blob/cfef3b68f103f6d9e1f0908536df1bfae2dc1730/llvm/cmake/modules/CMakeLists.txt#L6 since was the library failing. And apparently the command now runs successfully with this workaround ... but I don't know what would be the actual fix(still trying to better understand the problem) for this issue so opening this thread here. Could be along the lines of changing the path that swift looks for then?

Also can follow up with an issue on swift repo as well.

cc @contributor-experience-workgroup should we introduce some kind of check in CI to ensure utils/build-script --swift-darwin-supported-archs "$(uname -m)" --xcode runs successfully? Seems like cmake changes either on llvm or swift side could aftect it and contributors in general could run into issues when following GettingStarted for setup.

1 Like
2

AARRRGH this is getting out of hand...

This feels like a dilemma. If we launch a separate job, it will simply end up failing without blocking anything like the last one we had. On the other hand, it is okay to check the functionality of an IDE preference as part of a smoke test?

@contributor-experience-workgroup How come this affects only us external contributors :sweat_smile:? What IDE do you folks use?

1 Like
3

Maybe not on smoke test but have a separate job that people can trigger against their branch in those sort PRs that have large Cmake changes or llvm rebranchs?
I was also thinking that having a nightly that runs it (which I think you mention it use to run at some point) and when it fails notify a group of people that could look into it?

That was my question as well :laughing:
I spend a lot of time thinking it was something in my environment because it seemed that no one else was having this issue. It looks like --xcode is not that much used in day-to-day by many people.

But for external people, specially new contributors, is important for that to work because people work on a more limited time window, so when in that time that you set for trying to look into an issue, you are not able to get through the getting started and setup the project doesn't work it could make people loose interest on giving it a try.

1 Like
4

@LucianoPAlmeida Something fixed the generation :face_with_monocle:

5

Yes :)
Seems like the commit which changed the paths that caused the issue(one mentioned on the post) was reverted last week Revert "[CMake] Avoid `LLVM_BINARY_DIR` when other more specific vari… · apple/llvm-project@232c77e · GitHub on LLVM stable/20221013.

1 Like
6

PR: Fix Xcode project generation by bnbarham · Pull Request #6410 · apple/llvm-project · GitHub

@bnbarham Thanks, Ben!

1 Like