Why not read cmake dependencies from environment

I'm building o-mvll with VSCode, currently in src/CMakeLists.txt, there're NO_DEFAULT_PATH which prevent cmake to read dependencies' path from environment variables.

find_package(LLVM 14 REQUIRED CONFIG NO_DEFAULT_PATH)
find_package(Clang REQUIRED CONFIG. NO_DEFAULT_PATH)

find_package(spdlog REQUIRED CONFIG)
find_package(pybind11 REQUIRED CONFIG NO_DEFAULT_PATH)

However I think it's not very convinent when I'm using VSCode with settings.json:

{
    "cmake.sourceDirectory": "${workspaceFolder}/src",
    "cmake.generator": "Ninja",
    "cmake.environment": {
        "LLVM_DIR": "/usr/lib/llvm-14/cmake",
        "Clang_DIR": "/usr/lib/cmake/clang-14",
        "pybind11_DIR": "/usr/lib/cmake/pybind11"
    }
}

but this doesn't work, and cmake will give an error:

  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 let cmake use DIRs from "cmake.environment", I have to remove NO_DEFAULT_PATH: and I prefer to set dependencies path in "cmake.environment" like below:

find_package(LLVM 14 REQUIRED CONFIG)
find_package(Clang REQUIRED CONFIG)

find_package(spdlog REQUIRED CONFIG)
find_package(pybind11 REQUIRED CONFIG)

For what I understand, it could be more convinent if we can use the environment approach for VSCode. because there's no "best practice to develop o-mvll", I'm not sure if NO_DEFAULT_PATH is actually a more reasonable choice in your local workflow. I would greatly appreciate hearing your opinion!

open-obfuscator / o-mvll

Why not read cmake dependencies from environment #5