Suppress needlessly alarming messages

[dabrahams]

These packages are not marked REQUIRED and when this project is used as a dependency of another CMake project they don't need to be findable when this CMakeLists.txt is read. They may in fact be found later in the configuration process, so the messages when they actually are needed, so the messages

-- Could NOT find dispatch (missing: dispatch_DIR)
-- Could NOT find Foundation (missing: Foundation_DIR)
-- Could NOT find XCTest (missing: XCTest_DIR)

are needlessly alarming.

Replace this paragraph with a description of your changes and rationale. Provide links to an existing issue or external references/discussions, if appropriate.

Checklist

• I've added at least one test that validates that my change is working, if appropriate
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary

[compnerd]

I suppose that this is fine. The problem is that QUIET is now applied unconditionally which means that when building the toolchain, we would not see in the logs if a mismatched version of these toolchain vended libraries are accidentally picked up. Perhaps it makes sense to conditionalise this on whether the package is being built as a top-level package?

CC: @etcwilde - Evan may have thoughts on the logging as well.

[compnerd]

@swift-ci please test

[etcwilde]

Yeah, I'd prefer to keep the logging. If they aren't a WARNING, and aren't an ERROR, they won't prevent you from continuing and are just informational, but if they aren't emitted and you were expecting to find them, having that in the log is definitely preferable to scratching your head wondering why things were getting built weirdly.

[natecook1000]

Maybe instead of marking these QUIET, we could add an additional message that contextualizes the output?

[dabrahams]

Maybe you could conditionally find_package based on the conditions that actually require them, and under those conditions make them REQUIRED? The current situation:

• For developers of this package, defers errors to link time with a much harder-to-understand message, after you've wasted a bunch of time proceeding past an unrecoverable condition
• For consumers of this package, produces confusing messages—in my case, for example XCTest actually is found, only later. So it's not just alarming, it's misleading to see this message.

[compnerd]

@dabrahams the condition that you need find_package is not a very helpful heuristic. We cannot infer if the user is intending to build against a custom build of any of those libraries or against the toolchain distribution of the libraries. The common case for building this library with CMake is intended to be against a custom build and you should do a find_package.

I can see an argument for eliding the find_package on macOS as we cannot build the dependencies on macOS in the OSS release, but outside of that, I think that the current behaviour is the preferred option.

[dabrahams]

@compnerd I don't understand what your comment means. I wasn't suggesting any heuristic. I don't think there's any reason it should make a difference which version of those libraries are needed for any particular build. Assuming you want to keep the find_package calls, all I'm suggesting is that they be marked QUIET.

[compnerd]

The normal usage for the build is with a custom build of the dependencies and therefore the default should be non-QUIET. The special case is Darwin, where these are system provided, so we could exclude the checks there.

[dabrahams]

I still don't understand the "therefore." Does using a custom build of the dependencies require that they have been set up by that point?

Are they really dependencies at all? dispatch only appears in that file. I… guess Foundation is a real dependency. And XCTest is only a dependency if you're building testing, so it find_package for that should only happen if BUILD_TESTING is set.

[compnerd]

I still don't understand the "therefore." Does using a custom build of the dependencies require that they have been set up by that point?

Yes, the custom build of dependencies requires that they are setup by that point (except on Darwin where they are system provided).

Are they really dependencies at all? dispatch only appears in that file. I… guess Foundation is a real dependency.

Yes, dispatch is a transitive dependency due to Foundation.

And XCTest is only a dependency if you're building testing, so it find_package for that should only happen if BUILD_TESTING is set.

That is a great suggestion! We should conditionalise the find_package(XCTest) under BUILD_TESTING.