[CMake][Doc] Document BUILD_DUMMY_LIBTVM and source-build for compilation

[nuri-yoo]

Source builds default to BUILD_DUMMY_LIBTVM=ON, which produces a runtime-only libtvm that loads prebuilt rt.dylib artifacts but silently breaks mlc_llm compile later — LLVM target codegen is not linked, so calls like tvm.codegen.llvm.GetDefaultTargetTriple fail with an opaque "global function not registered" error after the user has finished a long build. Today the default is discoverable nowhere: not in CMakeLists.txt comments, not in cmake/gen_cmake_config.py prompts, not in docs/install/mlc_llm.rst (which only mentions the TVM install doc indirectly).

This change makes the default and its escape hatch visible at the two earliest natural points. CMakeLists.txt emits a message(STATUS ...) immediately after the existing set(BUILD_DUMMY_LIBTVM ON) so anyone running cmake .. sees what the default produces and how to switch (-DBUILD_DUMMY_LIBTVM=OFF -DUSE_LLVM=<llvm-config path>); the message uses the same form as the surrounding message(STATUS ...) calls (lines 23, 40, 66, 124). docs/install/mlc_llm.rst gains a .. note:: under "Option 2. Build from Source / Step 2" with the matching cmake invocation for macOS (Homebrew LLVM) and Linux (apt), plus an nm build/tvm/libtvm.{dylib,so} | grep -ci llvm check to confirm LLVM ended up in the resulting libtvm.

No behavioural change; BUILD_DUMMY_LIBTVM=ON stays the default — it is the right default for the dominant runtime-only use case (prebuilt wheel users). Anyone wanting compilation support flips the two flags as documented.

[gemini-code-assist]

Code Review

This pull request introduces a status message in CMakeLists.txt to inform users when BUILD_DUMMY_LIBTVM is enabled and updates the documentation with instructions for building an LLVM-enabled libtvm for model compilation. Feedback was provided regarding the implementation of BUILD_DUMMY_LIBTVM as a hardcoded variable, which prevents users from overriding it via the command line, and a correction was suggested for the documentation to ensure the USE_LLVM flag is passed correctly to CMake without premature shell substitution.

[gemini-code-assist]

The status message informs users that they can re-configure with -DBUILD_DUMMY_LIBTVM=OFF. However, line 58 uses set(BUILD_DUMMY_LIBTVM ON), which creates a normal variable that shadows any cache variable set via the command line (e.g., using -D). This means that passing -DBUILD_DUMMY_LIBTVM=OFF to cmake will have no effect on the build, as the local variable will override the cache value. To make this "escape hatch" functional, line 58 should be changed to an option() or a cache variable.

[gemini-code-assist]

The command $(llvm-config --link-static) uses shell substitution syntax which executes the command in the shell before passing the result to cmake. Since llvm-config --link-static without other flags (like --libs) typically produces no output, the USE_LLVM variable will be set to an empty string. To correctly pass the command string to CMake (which TVM's build system expects so it can handle the flags itself), it should be provided as a literal string.

Suggested change

	-DUSE_LLVM="$(llvm-config --link-static)"
	-DUSE_LLVM="llvm-config --link-static"

[nuri-yoo]

Both review points addressed in 074b9ba:

• set(BUILD_DUMMY_LIBTVM ON) → option(BUILD_DUMMY_LIBTVM "..." ON) so the documented -DBUILD_DUMMY_LIBTVM=OFF actually takes effect via the cache (the previous normal-variable form silently shadowed it on some configurations).
• The Linux example switched from -DUSE_LLVM="$(llvm-config --link-static)" (which collapses to an empty string at shell parse time, since llvm-config --link-static alone produces no output) to -DUSE_LLVM="llvm-config --link-static", matching how cmake/utils/FindLLVM.cmake invokes the tool itself. The macOS example was already a literal string with the path expanded by brew --prefix, so it remains unchanged.