Generate cmakelists relying on FindX.cmake files

[SirLynix]

I had a discussion on twitter about xmake vs cmake (see here: https://twitter.com/SirLynix/status/1394952159301623808) and one of the feature of xmake I talked about was it's ability to generate cmakelists (so you could use cmake libraries and use your xmake library in cmake projects).

However, I think xmake is lacking one feature to make that really possible.
When you generate a cmakelists using xmake in a project using dependencies, it had this kind of code:

target_link_libraries(NazaraAudio PRIVATE
    sndfile
    vorbis
    vorbisenc
    vorbisfile
    opus
    FLAC
    ogg
    NazaraCore-d
)
target_link_directories(NazaraAudio PRIVATE
    C:/Users/Lynix/AppData/Local/.xmake/packages/l/libsndfile/1.0.30/dbdb70e3729b4f73ba82df05616e085b/lib
    C:/Users/Lynix/AppData/Local/.xmake/packages/l/libvorbis/1.3.7/fa7769e029814b4283ea548596ffd9f8/lib
    C:/Users/Lynix/AppData/Local/.xmake/packages/l/libopus/1.3.1/63248ec97dba432d9b9e5386cf0e78c5/lib
    C:/Users/Lynix/AppData/Local/.xmake/packages/l/libflac/1.3.3/708a913260e6467094af3c408b913ada/lib
    C:/Users/Lynix/AppData/Local/.xmake/packages/l/libogg/v1.3.4/1be92a67316a4fde975545f16c970cc8/lib
    bin/windows_x64_debug
)

This makes it impossible to commit a cmakelists on your repository to use CMake FetchContent feature, as it would have to use xmake beforehand.

So I had an idea, why not have a second cmakelists generator which will generate some FindPackage.cmake (or use another cmake way) in order to be able to commit those cmake files on a repository

At least something that will let you use cmake to tell where libraries are.

[waruqi]

is this? https://github.com/xmake-io/xmake/issues/1268

set_project("test")
target("test")
    set_kind("static")
    add_files("src/*.cpp")
    add_rules("utils.install.cmake_importfiles")

in Cmakelist.txt

find_package("test::test") 

projectname::targetname

$ tree /tmp/install
/tmp/install
├── include
└── lib
    ├── cmake
    │   └── test
    │       ├── testConfig.cmake
    │       ├── testConfigVersion.cmake
    │       ├── testTargets-release.cmake
    │       └── testTargets.cmake
    ├── libtest.a

https://xmake.io/#/manual/custom_rule?id=utilsinstallcmake_importfiles

[SirLynix]

It's not exactly the same.

What I'm talking about is a feature allowing you to generate a cmakelists for your library which doesn't have to rely on xmake (and will generate a findX.cmake for your dependencies). Which then would be compatible with another project (using cmake) to use your library using FetchContent or cmake-gui without needing to install xmake.

I don't like this feature a lot (and I don't need it) but it would make it easier to use xmake in a cmake-dominated world.

[waruqi]

Generate portable cmakelist.txt with cmake/find_package?

It may be possible for simple packages, but cmake does not fully implement the features of xmake/add_requires, and I cannot fully map to cmake/find_package, such as packages in the xmake-repo repository, but these packages do not exist in vcpkg or conan.

There are also semantic versions, custom package configurations, and more.

edit:

But if your project does not use dependent packages at all, the currently generated cmakelist.txt is already universal.

[waruqi]

If for xmake.lua that only uses vcpkg and conan packages, I can consider generating cmakelists.txt with find_package, which can be done

[SirLynix]

I wasn't thinking of mapping everything xmake does to cmake files, I know it's not possible.

I was thinking of just collecting package names (and maybe some package info which may help) to output generic FindPackage.cmake which would just allow users to tell where the package is (and just search on the system).

So yeah the idea is to accept the generation of portable cmakelists which won't do as good as xmake does.

[waruqi]

I wasn't thinking of mapping everything xmake does to cmake files, I know it's not possible.

I was thinking of just collecting package names (and maybe some package info which may help) to output generic FindPackage.cmake which would just allow users to tell where the package is (and just search on the system).

So yeah the idea is to accept the generation of portable cmakelists which won't do as good as xmake does.

Collect other package name information, I originally planned to do it, because this issue https://github.com/xmake-io/xmake/issues/1140 will also need them, I will put this information in the package definition.

[xq114]

I think a plausible solution is to generate FindXXX.cmake by package information. For instance, consider a package

{
name = "foo"
includedirs = {"<installdir>/include/fooinc"}
linkdirs = {"<installdir>/lib"}
links = "foo"
}

xmake can generate a Findfoo.cmake

if(USE_PKGCONFIG)
  if(NOT DEFINED PKG_CONFIG_FOUND)
    find_package(PkgConfig)
  endif()
  pkg_check_modules(foo QUIET foo)
endif()

find_path(foo_INCLUDE_DIR fooinc.h PATHS ${CMAKE_PREFIX_PATH}/include/fooinc)
find_library(foo_LIBRARIES foo PATHS ${CMAKE_PREFIX_PATH}/lib)

include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(foo
  FOUND_VAR foo_FOUND
  REQUIRED_VARS
    foo_LIBRARIES
    foo_INCLUDE_DIR
)

I'm not so familiar with cmake and the former script may not work though, it's just for explanation. I know cmake uses environment variable CMAKE_PREFIX_PATH to set find_xxx prefix directories. Although the directory information is extracted from xmake, it should be the same case for user installed packages, since we aim to keep the package structure in xmake-repo. Therefore the script is hopefully to work for most packages, as long as CMAKE_PREFIX_PATH is correctly set by user. At least, the script will be expected to work in the xrepo virtual environment.

[waruqi]

thanks, maybe I will consider improving it in the next version.

[waruqi]

We can also define a xmake package and use xrepo-cmake to use this package in cmakelists.