Feature of manifest mode which makes it easy to add the default CMake targets of each dependency to a CMakeLists.txt.

[NickStrupat]

I'm loving the manifest mode of vcpkg. It is vastly improving the way C++ dependencies are managed. It's getting very close to npm, pip, nuget, etc. in terms of terseness and simplicity of linking (many) libraries with just a find_package call and a target_link_libraries call.

It has me wondering about a nice way to programmatically consume the output of the usage files. I'm not sure if that's the right description of the output of a vcpkg install where you get:

The package sqlite3 provides CMake targets:

    find_package(unofficial-sqlite3 CONFIG REQUIRED)
    target_link_libraries(main PRIVATE unofficial::sqlite3::sqlite3)

Essentially what I'm proposing is for a feature which automatically adds to CMakeLists.txt the default CMake targets from all of one's dependencies. I'm imagining adding something like this to one's main CMakeLists.txt:

    find_package(${VCPKG_PROJECT_PACKAGES} CONFIG REQUIRED)
    target_link_libraries(main PRIVATE ${VCPKG_PROJECT_LIBRARIES})

... which would behave as if one had the following:

{
    "name": "project-name",
    "version": "0.0.1",
    "dependencies": [
        "magic-enum",
        "nlohmann-json",
        "cli11",
        "sqlite3",
        "sqlite-orm"
    ]
}

... and enumerated them manually in CMakeLists.txt:

find_package(magic_enum CONFIG REQUIRED)
find_package(nlohmann_json CONFIG REQUIRED)
find_package(CLI11 CONFIG REQUIRED)
find_package(unofficial-sqlite3 CONFIG REQUIRED)
find_package(SqliteOrm CONFIG REQUIRED)

target_link_libraries(main PRIVATE
    magic_enum::magic_enum
    nlohmann_json::nlohmann_json
    CLI11::CLI11
    unofficial::sqlite3::sqlite3
    sqlite_orm::sqlite_orm
)

[Osyotr]

As it may seem good for single target projects, it's not good for everything else. Please, make explicit calls to find_package and target_link_libraries. Some things to consider:

1. Packages may not export cmake config file.
2. CMake may not have Find-module for this package
3. Libraries may provide multiple targets to link to.
4. These targets may conflict with targets from other packages.
5. Some libraries are configurable by setting variables before find_package call.
6. Some libraries provide targets only for some platforms.
   Also, doing so will essentially lock you into vcpkg.

[NickStrupat]

Yes, and what I'm proposing would work just fine for projects which produce a single target with find_package and target_link_libraries.

I don't see how adding this feature would regress the existing implementation, nor change any of the points you've listed. It would however simplify the use of vcpkg for most of the ports and a lot of their consumption use cases.