Conversation
|
Great work. I also thought about this. The approach is very similiar to what was done to https://github.com/nlohmann/json with nlohmann/json#4799. Then, I noticed ... Is this temporary approach with a file with This approach is not using modules natively but rather as an interface to the original way. Does this method work without disadvantages? |
|
This is the best way to my knowledge to support modules on top of a header-only or header/source library, allowing continued support for older versions while providing newer features as an option. I'm not aware of any disadvantages to it besides a being additional translation unit to compile, but if I am wrong please correct me. The only glaring difference in API is that detail symbols are hidden as they are not exported, but in my opinion that's probably better not to expose detail symbols and flood IDE suggestions with implementation details. |
|
What about compiled libraries? Is it possible to have the traditional method and modules installed in parallel? I am thinking of repositories that ship compiled This is relevant here, https://aur.archlinux.org/packages/cpp-httplib-compiled . |
|
Yes I believe it's possible to use shared/static libraries with modules, all of my modular projects compiled to shared libraries that an executable consumes |
|
@mikomikotaishi, thanks for the fine pull request! It's fantastic, but my concern is that someone needs to update @sum01 @jimmy-park @Tachi107 do you have any thought about this pull request? |
|
I could create a Python script, or some other kinds of automated means of updating, which you could run every time it is updated. Until then I would be OK with maintaining this file, as it is a simple process. Such a script would probably comb through the file and add any symbols not part of a detail or internal namespace, or prefixed with an underscore, etc. However, I am curious why it is not feasible to update the file manually. In case it isn't clear how, one can update the file by adding a |
|
I have also seen some repositories use bots to push some commits too. Potentially one such bot could be set up to automatically populate the module with new changes each time there is a mismatch. I don't know anything about how to set this up, but I have seen this before and it could potentially be a solution (but I think the simplest one is just to run a Python script each time any update to the library happens). |
|
Anyway, I think this could be one such way of automatically updating the module. |
|
@mikomikotaishi thanks for the additional explanation. I am ok with the following your suggestion.
We could automatically generate |
|
OK, that makes sense to me. (I don't know anything about how to run GitHub Actions or write scripts for it however, so I'm afraid the most I can do is create a script for this.) |
|
I'm not sure why there were failing workflows as I didn't change anything in the core library |
|
Never mind, it seems the failing CI is happening upstream too. |
|
If the file can be run during the build process (and if the output consists of machine-generated files, it should *only* run during build time), then the destination directory should be configurable (maybe defaulting to the the current working directory). Even better, if the output is a single file, the script should allow the user to specify the output file itself (full path).
This is because downstreams (like Debian, which is what I maintain the meson build scripts for) may have some requirements on where build products should be stored.
|
|
@Tachi107 CMake needs to know what the output directory is ahead of time to compile the module. How do you propose to solve this? |
|
@yhirose I think there is one possible solution to allow both the directory to be user-specified while still supporting CMake module building, which is probably just to have the Python script generate the CMake file too. I don't know if this is too convoluted or awkward of a design though, so please do tell me your thoughts. |
|
Hi Miko,
On Tue Dec 9, 2025 at 10:46 PM CET, Miko wrote:
@Tachi107 CMake needs to know what the output directory is ahead of time to compile the module. How do you propose to solve this?
You should use CMake's add_custom_command() function to invoke the
script and pass it the output file path
https://cmake.org/cmake/help/latest/command/add_custom_command.html
Meson has a similar function, but I can do that myself after this gets
merged.
|
Tachi107
left a comment
Tachi107
left a comment
There was a problem hiding this comment.
Some feedback now that I have been able to look at the whole code :)
|
Is there a reason to try and add module support when the library itself is C++11? Not to mention, Cmake v3.28 adds built-in module support, which isn't being used either. |
|
This library being C++11 does not require programmes depending on it being C++11. I support the modules. |
|
Indeed, some people who use C++20 and onward may wish to consume the library with the module rather than the header. This is precisely what modules are designed to improve for compilations, as re-including the same large header in multiple locations massively increases build times whereas modules are built only once and then imported/linked. |
|
I understand you can use older standards on newer ones, but I mean trying to add support where it isn't "supported" seems unnecessary. As for having to re-compile, why not use pre-compiled headers (Cmake v3.16 feature), or the compiled version of this library? |
|
Precompiled headers are not a standard language feature, they are just a compiler trick. Modules provide a very specific API and very specific features for library encapsulation. For example, we may want to avoid including httplib's macros or avoid adding detail/implementation symbols into scope, which overwhelms autocomplete on IDEs with irrelevant symbols. Even splitting the library into a header/source division still leaves a very large header that gets recompiled each time. As for the question of "support", this specific wrapper style (a module which includes the header and then re-exports the symbols) is how most libraries built with C++11/14/17 provide module support (such as Boost, Poco, etc.) This is the simplest way to do it to my knowledge, and it's not a hastily tacked-on hack. You can see in other libraries this is how originally header-libraries are wrapped for modules. |
|
Hi, sorry for the silence on this issue. I've been busy with an exam, but I'll return to this and send a solution today or tomorrow. |
|
@yhirose Hi, I am sorry but I am completely lost as to how to actually generate a module correctly from the header. I was considering using |
|
I personally would rather manually maintain the module file for the time being, but if someone more skilled at parsing C++ wants to take a crack at this please feel free. |
|
@mikomikotaishi Thanks for your willingness. However, I am now thinking of closing this pull request for the maintenance reason I commented on before. I would like to confirm that you will commit to updating modules/httplib.cppm whenever new external symbols are added or existing symbols are removed/renamed by contributors. I am not going to wait for this update to happen. This update must be done by you before I release a new version. Otherwise, httplib.h will be shipped with an incompatible, out-of-date httplib.cppm. If you accept this responsibility from now on, I will reconsider it. |
|
@yhirose Could you please review the current changes and give your feedback on the current state? |
|
Thank you for all your hard work! I just tried to build with g++-15 installed from homebrew on macos. I made the following test file. // test-cpp-modules.cc
import httplib;
using namespace httplib;
int main() {
Server svr;
svr.Get("/hi", [](const Request & /*req*/, Response &res) {
res.set_content("Hello World!", "text/plain");
});
svr.listen("0.0.0.0", 8080);
}Then, I did the following: > g++-15 -std=c++20 -fmodules-ts -x c++ -c httplib.cppm
> g++-15 -std=c++20 -fmodules-ts test-cpp-modules.cc httplib.o -o test-cpp-modulesBut when I run the second command to make the executable file, the compiler gave me errors below... Do you have any clue? |
Co-authored-by: Andrea Pappacoda <andrea@pappacoda.it>
|
It looks like the problem is that GCC has a broken module implementation. Adding #include <new>
#include <typeinfo>inside your In my experience there is no need to include those headers on Clang; that's why I'm convinced it's a GCC bug. |
|
If I put the two lines before When the lines are added after |
|
Also I confirmed that the latest Apple Clang in Xcode 26.2 doesn't work. So I don't know how I can apply this C++ module support on my mac... |
|
Did you make sure to link back to the source file, which contains the implementations of most of these listed symbols? I had a similar error until I realised I had not done the aforementioned step. |
|
Could you please try the following with g++-15 on your machine to see if you get the same error or not? If you get the same error, could you show me how you can fix the problem? Thanks.
// test-cpp-modules.cc
import httplib;
#include <new>
#include <typeinfo>
using namespace httplib;
int main() {
Server svr;
svr.Get("/hi", [](const Request & /*req*/, Response &res) {
res.set_content("Hello World!", "text/plain");
});
svr.listen("0.0.0.0", 8080);
} |
|
This seemed to work for me: $ g++ -std=c++20 -c httplib.cc -o httplib.o
$ g++ -std=c++20 -fmodules-ts -x c++ -c httplib.cppm -o httplib_module.o
$ g++ -std=c++20 -fmodules-ts test.cpp httplib.o httplib_module.o -o testAlso, if you are getting a compiler crash or internal error on GCC, move the |
|
Sorry, but the following still gives me the same exact errors regardless whether |
|
Have you cloned the most recent revision? Specifically, the generated module should have export extern "C++" {
#include "httplib.h"
}Lacking |
|
I am using the latest ...
export module httplib;
export {
#include "httplib.h"
} |
|
I'm confused what you mean, you say it includes |
|
You are right. I'll clone the latest. Sorry for the confusion. |
|
I finally got it to build with C++ modules. Thanks for your help. ( #include <new>
#include <typeinfo>
import httplib;
using namespace httplib;
int main() {
Server svr;
svr.Get("/hi", [](const Request & /*req*/, Response &res) {
res.set_content("Hello World!", "text/plain");
});
svr.listen("0.0.0.0", 8080);
} |
|
Fantastic! Is there anything left to do before we can finish this PR? |
|
I just took a look at the code, and I realized that the C++ module generation isn't related to split.py. It would be better to move this functionality to a separate file, such as gen_cpp_module.py. So, could you please move the module generation code to gen_cpp_module.py and revert the changes to split.py? That's all! |
|
But I think a lot of the logic that is used to construct the module is dependent on the code splitting script, and it's simpler to ensure the module generation takes place after the header is split into header and source, etc. I just personally don't think that there is much to gain from dividing the logic, especially if module generation is only allowed when the library is compiled, etc. |
|
It's fine with me if |
|
@yhirose I split the script into two files and tested it again with both manually calling the script and doing it from CMake, and it looks good to me. |
mikomikotaishi
force-pushed
the
master
branch
from
dbc9f83 to
563e3b2
Compare
|
Looks good to me. Thanks for all your hard work! |
6 participants
This pull request adds support for C++20 modules through CMake. It is enabled by the
HTTPLIB_BUILD_MODULESoption (which requiresHTTPLIB_COMPILEto be enabled, though it probably doesn't have to - I only forced this requirement because it seems to make the most sense to force the library to compile if modules are to be compiled).