3 ms·

C++ modules need a lot of communication between build systems, compilers, packaging environments, and other dev tools like clangd. Given some of that interop is

C++ modules need a lot of communication between build systems, compilers, packaging environments, and other dev tools like clangd. Given some of that interop isn't available anywhere due to missing or at least unimplemented protocols, I expect XMake is overpromising here. The CMake blogs are more qualified: 1. General named module use: https://www.kitware.com/import-cmake-c20-modules/ https://www.kitware.com/import-cmake-c20-modules/ 2. Importing the std module: https://www.kitware.com/import-std-in-cmake-3-30/ https://www.kitware.com/import-std-in-cmake-3-30/

coffeeaddict1 2y ago
Yeah, that was my thought too. I doubt it supports modules as well as CMake 3.30 (which is not amazing btw) but you never know.
- arthapz 2y ago
  As the xmake C++ module main contributor, i can affirm that xmake module support is ahead of cmake, i added support for gcc, clang and msvc, headerunits, import std, automatic reuse of bmi when flags are compatible,import module from an external package (like glm or vulkan_hpp) and i’m closely watching compilers repository to support new things before compiler release for clangd i can't do much currently, there is a PR that add some support, i tried it, but doesn't require for now buildsystem intervention For example: add_requires("vulkan-headers", {configs = {modules = true}}) # xmake.lua target("test-vk") set_languages("c++latest") add_files("src/\*.cpp") set_policy("build.c++.modules", true) add_packages("vulkan-headers") // main.cpp import std; import vulkan_hpp; int main() { auto vk_context = vk::raii::Context(); const auto exts = vk_context.enumerateInstanceExtensionProperties(); for(auto &&ext : exts) std::println("{}", std::string{ext.extensionName}); return 0; } // result > xmake f --toolchain=llvm --runtimes="c++_shared" --yes; xmake b checking for platform ... windows checking for architecture ... x64 [ 0%]: <test-vk> generating.module.deps src\main.cpp [ 0%]: <test-vk> generating.module.deps F:\llvm\bin\..\lib\..\share\libc++\v1\std.cppm [ 0%]: <test-vk> generating.module.deps F:\packages\xmake\v\vulkan-headers\1.3.275+0\ae359cf8d45b4d049acf1ae7350e6dc3\modules\b028617b\vulkan.cppm [ 12%]: <test-vk> compiling.module.release std [ 12%]: <test-vk> compiling.module.release vulkan_hpp [ 62%]: compiling.release src\main.cpp [ 75%]: linking.release test-vk.exe [100%]: build ok, spent 5.64s > xmake run VK_KHR_device_group_creation VK_KHR_external_fence_capabilities VK_KHR_external_memory_capabilities VK_KHR_external_semaphore_capabilities VK_KHR_get_physical_device_properties2 VK_KHR_get_surface_capabilities2 VK_KHR_surface VK_KHR_win32_surface VK_EXT_debug_report VK_EXT_debug_utils VK_EXT_swapchain_colorspace VK_KHR_portability_enumeration VK_LUNARG_direct_driver_loading
kleiba 2y ago
> C++ modules need a lot of communication between build systems, compilers, packaging environments, and other dev tools like clangd. As someone who doesn't program in C++ I've got to ask: why is that?
- xigoi 2y ago
  It wouldn’t be C++ if it didn’t make everything unnecessarily complicated.

coffeeaddict1 2y ago

Yeah, that was my thought too. I doubt it supports modules as well as CMake 3.30 (which is not amazing btw) but you never know.

arthapz 2y ago
As the xmake C++ module main contributor, i can affirm that xmake module support is ahead of cmake, i added support for gcc, clang and msvc, headerunits, import std, automatic reuse of bmi when flags are compatible,import module from an external package (like glm or vulkan_hpp) and i’m closely watching compilers repository to support new things before compiler release for clangd i can't do much currently, there is a PR that add some support, i tried it, but doesn't require for now buildsystem intervention For example: add_requires("vulkan-headers", {configs = {modules = true}}) # xmake.lua target("test-vk") set_languages("c++latest") add_files("src/\*.cpp") set_policy("build.c++.modules", true) add_packages("vulkan-headers") // main.cpp import std; import vulkan_hpp; int main() { auto vk_context = vk::raii::Context(); const auto exts = vk_context.enumerateInstanceExtensionProperties(); for(auto &&ext : exts) std::println("{}", std::string{ext.extensionName}); return 0; } // result > xmake f --toolchain=llvm --runtimes="c++_shared" --yes; xmake b checking for platform ... windows checking for architecture ... x64 [ 0%]: <test-vk> generating.module.deps src\main.cpp [ 0%]: <test-vk> generating.module.deps F:\llvm\bin\..\lib\..\share\libc++\v1\std.cppm [ 0%]: <test-vk> generating.module.deps F:\packages\xmake\v\vulkan-headers\1.3.275+0\ae359cf8d45b4d049acf1ae7350e6dc3\modules\b028617b\vulkan.cppm [ 12%]: <test-vk> compiling.module.release std [ 12%]: <test-vk> compiling.module.release vulkan_hpp [ 62%]: compiling.release src\main.cpp [ 75%]: linking.release test-vk.exe [100%]: build ok, spent 5.64s > xmake run VK_KHR_device_group_creation VK_KHR_external_fence_capabilities VK_KHR_external_memory_capabilities VK_KHR_external_semaphore_capabilities VK_KHR_get_physical_device_properties2 VK_KHR_get_surface_capabilities2 VK_KHR_surface VK_KHR_win32_surface VK_EXT_debug_report VK_EXT_debug_utils VK_EXT_swapchain_colorspace VK_KHR_portability_enumeration VK_LUNARG_direct_driver_loading

kleiba 2y ago

> C++ modules need a lot of communication between build systems, compilers, packaging environments, and other dev tools like clangd. As someone who doesn't program in C++ I've got to ask: why is that?

xigoi 2y ago
It wouldn’t be C++ if it didn’t make everything unnecessarily complicated.