Improve dependency discovery for MLIR-AIE

[thomthehound]

Summary

MLIR-AIE is currently carrying too much dependency-specific path handling in its own CMake code. That includes: hard-coded package locations, manually assembled include and library paths, and assumptions that do not hold across both Linux and Windows installs.

That makes the repo-side CMake harder to maintain, as well as making it unnecessarily difficult to expose a clean interface for native C++ applications.

These changes put the platform and package-layout knowledge in the "find" modules that own them. MLIR-AIE can then consume stable CMake contracts instead of reproducing the discovery logic itself.

This is a drop-in replacement for the existing finders, so it does not require any changes to MLIR-AIE itself (or any other downstream consumers). It also does not change the existing variable-based interface, so existing consumers remain compatible. This only adds new target-based interfaces and fixes some missing or broken behavior in the released packages.

Changes

XRT

FindXRT.cmake now provides XRT::xrt_coreutil for target-based consumers while preserving the existing XRT_COREUTIL library-path variable and other established variables.

Linux prefers XRT's installed config package and retains direct installed-layout discovery for packages that do not provide one.

Windows links through xrt_coreutil.lib. A local xrt_coreutil.dll is not supplied with the Windows XRT SDK because the installed driver provides the runtime DLL. Previously, one was assumed. However, existing support for source-built XRT installations where a local test DLL is present is retained.

Existing Windows packages are given /Zc:__cplusplus so MSVC C++17 consumers use XRT's std::any interface instead of incorrectly falling back to Boost because they think the compiler is from 1997(!!!).

AIEBU

A new FindAIEBU.cmake supports both a standalone Linux installation and the AIEBU package bundled with the Windows XRT SDK (or a custom XRT/AIEBU build).

It exposes AIEBU::aiebu_static, repairs the missing public include directory in the current Windows SDK, and preserves the MSVC runtime required by the static library. New packages can report that runtime directly; existing packages use a compatibility fallback.

This removes the need for MLIR-AIE to search a fixed list of Linux package directories.

LibXAIE

FindLibXAIE.cmake retains its existing variable-based interface while adding:

• explicit installation selection through LibXAIE_ROOT;
• Windows installed-prefix support;
• lib64 and GNU multiarch library directories;
• support for both xaiengine and xaienginecdo.

Headers and libraries are selected from the same explicit prefix.

Effects

This is the first major step in the larger CMake infrastructure overhaul as mentioned in the MLIR-AIE ROADMAP.md.

The immediate benefit is simpler MLIR-AIE CMake:

• dependency locations and platform differences no longer need to be reconstructed in the main repository;
• custom installations can be selected without copying files into expected system directories;
• Windows and Linux builds can use the same dependency contracts;
• existing variable-based callers remain compatible.

I am finishing up work on a larger CMake package for MLIR-AIE itself, which will better take advantage of these improvements. That package will expose native host support through targets such as AIE::HostUtils, allowing a C++ application to link normal CMake targets instead of manually collecting XRT headers, libraries, compiler options, runtime settings, and platform-specific paths.

Testing

• Built MLIR-AIE from a clean checkout with only these changes applied to cmake/modulesXilinx.
• Passed the complete Windows check-aie suite.
• Built and ran a Linux consumer using XRT, AIEBU, and LibXAIE together.
• Tested XRT through both its config package and a config-free GNU multiarch installation.
• Tested independent Linux XRT and AIEBU installation prefixes.
• Configured against the distributed Windows XRT SDK.
• Configured against a source-built Windows XRT installation both with and without a local xrt_coreutil.dll.
• Tested XRT selection through XRT_ROOT and CMAKE_PREFIX_PATH.

[thomthehound]

@jgmelber I think this could potentially make our lives much easier when building CMake examples. At least, once I wrap up my follow-on patch for MLIR-AIE, that is.