修正 mxcc MACA 路径处理

[ghangz]

该 PR 修正 mxcc 相关路径处理逻辑，避免 MACA 安装路径变化时编译器定位失败。

这个修改面向沐曦 GPU 适配场景中比较容易影响开发、构建或验证稳定性的环节，把原来需要人工排查的问题前移到工具链、运行前检查或基准脚本中处理。实现上保持对现有默认行为的兼容，只在检测到明确配置、输入或环境异常时给出更直接的诊断，避免引入额外运行依赖，也方便维护者独立审阅该分支。

已在沐曦算力环境中完成对应分支验证，验证记录包含真实运行日志、命令输出和失败路径检查，本地归档目录为：E:/Documents/muxi/测试报告/mcTVM_new_toolchain_validation_20260608。提交分支：mengz/fix-mxcc-maca-path，目标仓库：MetaX-MACA/mcTVM。

[gemini-code-assist]

Code Review

This pull request refactors the MACA path discovery logic in mxcc.py by replacing a subprocess call to which with shutil.which and extracting the path inference into a helper function _maca_path_from_mxcc. It also introduces a new unit test file. The review feedback highlights two critical issues: first, _maca_path_from_mxcc should resolve the realpath of the executable before extracting its directory to correctly handle symlinks; second, the unit test should avoid manually mocking the tvm module in sys.modules to prevent global namespace pollution and potential CI test failures, and instead import the module directly.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

如果 mxcc 是一个符号链接（例如在 /usr/bin/mxcc 或 /usr/local/bin/mxcc 中创建了指向真实安装路径的软链接，这在多用户或容器环境中非常常见），当前实现会先提取软链接所在的目录（如 /usr/bin），然后再进行 ../.. 拼接和 realpath 解析。这会导致解析出来的路径是 / 而不是真实的 MACA 安装路径。

为了正确处理符号链接，应该先对 mxcc_path 调用 os.path.realpath 解析出真实的绝对路径，然后再计算其父目录和 MACA 根目录。

Suggested change

	def _maca_path_from_mxcc(mxcc_path):
	"""Infer MACA root from an mxcc executable path."""
	return os.path.realpath(os.path.join(os.path.dirname(mxcc_path), "../.."))
	def _maca_path_from_mxcc(mxcc_path):
	"""Infer MACA root from an mxcc executable path."""
	real_path = os.path.realpath(mxcc_path)
	return os.path.realpath(os.path.join(os.path.dirname(real_path), "../.."))

[gemini-code-assist]

在测试文件中通过手动构建 Mock 模块并直接修改 sys.modules（如 sys.modules.setdefault("tvm", tvm)）来导入 mxcc 是非常不推荐的做法。

1. 全局污染：这会全局污染 sys.modules。当与其他测试在同一个进程中运行（例如 CI 中的 pytest）时，后续真正需要使用 tvm 库的测试会拿到这个 Mock 的哑模块，导致大面积测试失败。
2. 代码冗余：手动 Mock 了大量的 TVM 内部结构，维护成本极高。

在 TVM 的测试体系中，测试运行时 tvm 模块应当已经是可导入的。建议直接使用标准的导入方式。

Suggested change

	import importlib.util
	import sys
	import types
	import unittest
	from pathlib import Path
	REPO_ROOT = Path(__file__).resolve().parents[3]
	MXCC_PATH = REPO_ROOT / "python" / "tvm" / "contrib" / "mxcc.py"
	def _register_global_func(*args, **_kwargs):
	if args and callable(args[0]):
	return args[0]
	return lambda fn: fn
	tvm_ffi = types.SimpleNamespace(register_global_func=_register_global_func)
	tvm = types.ModuleType("tvm")
	tvm.target = types.SimpleNamespace(Target=types.SimpleNamespace(current=lambda: None))
	tvm.maca = lambda *_args, **_kwargs: types.SimpleNamespace(exist=False)
	tvm.__path__ = []
	tvm_contrib = types.ModuleType("tvm.contrib")
	tvm_contrib.__path__ = []
	tvm_target = types.ModuleType("tvm.target")
	tvm_target.Target = object
	tvm_base = types.ModuleType("tvm.base")
	tvm_base.py_str = lambda value: value.decode("utf-8")
	tvm_contrib_utils = types.ModuleType("tvm.contrib.utils")
	tvm_contrib_utils.tempdir = lambda: None
	sys.modules.setdefault("tvm", tvm)
	sys.modules.setdefault("tvm.contrib", tvm_contrib)
	sys.modules.setdefault("tvm.target", tvm_target)
	sys.modules.setdefault("tvm.base", tvm_base)
	sys.modules.setdefault("tvm.contrib.utils", tvm_contrib_utils)
	sys.modules.setdefault("tvm_ffi", tvm_ffi)
	spec = importlib.util.spec_from_file_location("tvm.contrib.mxcc", MXCC_PATH)
	mxcc = importlib.util.module_from_spec(spec)
	mxcc.__package__ = "tvm.contrib"
	sys.modules["tvm.contrib.mxcc"] = mxcc
	assert spec.loader is not None
	spec.loader.exec_module(mxcc)
	import unittest
	from pathlib import Path
	from tvm.contrib import mxcc