[package] sqlite3/all: how to use components to mimic findSQLite3 and imported target SQLite::SQLite3

[SpaceIm]

According to CMake documentation https://cmake.org/cmake/help/v3.14/module/FindSQLite3.html:

• namespace of sqlite3 is SQLite (imported target is SQLite::SQLite3)
• we have to use find_package(SQLite3)

conan components doesn't seem to provide a way to handle this case.

[jgsogo]

This should be the last mile needed fo this transparent integration: conan-io/conan#7254

And then something like

cpp_info.filename = `SQLite3`
cpp_info.names["cmake_find_package"] = `SQLite`
cpp_info.components["all"].names["cmake_find_package"] = `SQLite3`

[SpaceIm]

Nice.

Maybe https://github.com/conan-io/conan is a better place to discuss about this, but there are also:

• libraries defining several imported targets without namespace, like if there was multiple distinct libraries (SPIRV-Tools and SPIRV-Cross for example).

• libraries defining an official namespace and a deprecated one (PROJ for example)

• libraries having a common namespace in multiple distinct libraries (Vulkan ecosystem, Qt and Boost I guess if they were modularized).

How to deal with that?

[jgsogo]

• libraries defining several imported targets without namespace, like if there was multiple distinct libraries (SPIRV-Tools and SPIRV-Cross for example).

When you consume a library via find_package(...) I would say that you always get the imported libraries inside a namespace. How are people usually finding SPIRV out there? Is there any widely used FindSPIRV.cmake (without namespaces) that we can use as a reference?

• libraries defining an official namespace and a deprecated one (PROJ for example)

IMO, this is like a project changing its name, we should focus on the new name and forget about the deprecated one.

• libraries having a common namespace in multiple distinct libraries (Vulkan ecosystem, Qt and Boost I guess if they were modularized).

Here it is an example: conan-io/conan#7254 (comment), different packages providing targets in the same namespace

[SpaceIm]

For SPIRV-Tools, here a subpart of the 4 LibTarget.cmake files:

SPIRV-ToolsTarget.cmake

...
# Create imported target SPIRV-Tools
add_library(SPIRV-Tools STATIC IMPORTED)

set_target_properties(SPIRV-Tools PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
)
...

SPIRV-Tools-optTargets.cmake

...
# Create imported target SPIRV-Tools-opt
add_library(SPIRV-Tools-opt STATIC IMPORTED)

set_target_properties(SPIRV-Tools-opt PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "SPIRV-Tools"
)
...

SPIRV-Tools-linkTargets.cmake

...
# Create imported target SPIRV-Tools-link
add_library(SPIRV-Tools-link STATIC IMPORTED)

set_target_properties(SPIRV-Tools-link PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "SPIRV-Tools-opt"
)
...

SPIRV-Tools-reduceTarget.cmake

...
# Create imported target SPIRV-Tools-reduce
add_library(SPIRV-Tools-reduce STATIC IMPORTED)

set_target_properties(SPIRV-Tools-reduce PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "SPIRV-Tools;SPIRV-Tools-opt"
)
...

Therefore, consumers would expect to use find_package(SPIRV-Tools), find_package(SPIRV-Tools-opt) etc. But conan cannot yet generate multiple find (cmake_find_package), or Config/Target (cmake_find_package_multi) files from one recipe.

[jgsogo]

I see. My personal opinion is that sometimes we need to be a little bit opinionated and try to force some changes when there is an outlier. I don't know if this library is one of those cases or we need to add an exception to the hook because this is an exception but everyone expects (and wants) to consume it that way.

[SpaceIm]

This issue can be closed, sqlite3 recipe now properly mimics official sqlite3 imported target and module filename.