kelteseth / arewemodulesyet Goto Github PK

async_simple's module module: https://github.com/alibaba/async_simple/blob/main/modules/async_simple.cppm

seastar's module: https://github.com/scylladb/seastar/blob/master/src/seastar.cc#L150

Both of the libraries are not on the list : (. So it might be better to use other properties (like github stars?) than vcpkg.

Also there is a project (not library as far as I know) inifinity use modules natively (we can get the usages at a random file under 'src', e,g., https://github.com/infiniflow/infinity/blob/main/src/network/buffer_writer.cppm). While it is not a library, I think it is a good example to give people more confidence.

And there is a high quality toy project using modules: https://github.com/davidstone/technical-machine, which is module native too.

I see there are some updates in https://github.com/kelteseth/arewemodulesyet/pull/24/files and https://github.com/kelteseth/arewemodulesyet/pull/26/files, but I can't find them in https://arewemodulesyet.org/

I have been updating Arrow on vcpkg whenever I do a new release (https://github.com/microsoft/vcpkg/pulls?q=is%3Apr+author%3Araulcd+is%3Aclosed) of Apache Arrow. We can add some details on the progress_overwrite about support, etcetera.

• Compiler Support

  • MSVC 2022
  • Clang
  • Apple Clang
  • GCC

• Build Tools

  • CMake
  • Ninja
  • Build2
  • Scons
  • Bazel
  • Meson
  • Gnu Make
  • Gradle

• Pre processor

  • Qt moc

It is error-prone that people have to update progress_overwrite.yml and progress.yml to update the change to the website. The process is somehow not easy even if there is a python script. It may be better to call the python script automatically when we deploy the website.

Hello there. I am the maintainer of Zork++

We've been supporting building C++ modules for more than a year now, so I thought that it will be interesting to add our project to the tracked ones in your list.

Would that be fine? Should we meet some special criteria before join such list?

Thanks for your time.

Just throw everything into a module file for now like vulkan-hpp does https://github.com/KhronosGroup/Vulkan-Hpp/blob/main/vulkan/vulkan.cppm . For this we could use python in combination with clang pip modules to parse existing code. We should start with the most used library there is: sqlite3 https://github.com/azadkuh/sqlite-amalgamation/blob/master/sqlite3.h

This would be neat to add to the table.

microsoft/vcpkg#38513

An issue used to mark that module support is done is closed regarding another issue: mesonbuild/meson#5024.

The issue used for module support indication is outdated and should not be used to indicate modules feature support in that tool, and the one mentioned above should be used instead.

When looking at the comments of this PR, we can see that even using a none modules project as a dependency can make problems in a modules project. My proposal:

1. LibraryX can be used in a modules project
2. LibraryX itself is a modules project
3. All of LibraryX dependencies are modules
4. LibraryX uses C++23 import std;
5. All of LibraryX dependencies are using C++23 import std;

One of the reasons it has been hard for people to adopt modules is that there are few practical tutorials on how to do it.

For example, modules make this possible for CMake (used by fmt)
https://github.com/vitaut/modules

It would be useful to add these resources to the website.

https://www.reddit.com/r/cpp/comments/1cdtabj/comment/l1hbkxk/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

• "💀 Needs support old library/compiler/build tool to even start adding support for odules." (should be "support for modules")

• "Tacking issue" (should be Tracking Issue) in the main table header

As reported by the author at https://www.reddit.com/r/cpp/comments/1cdtabj/comment/l1ixxtk/

Since currently we only have 2 (two) libraries, having a 50% increase is something! 😀