Add C++ modules support

[mikomikotaishi]

This pull request adds support for C++20 modules through CMake. It is enabled by the HTTPLIB_BUILD_MODULES option (which requires HTTPLIB_COMPILE to 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).

[Spixmaster]

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 using ... for the meantime while modules and no modules are supported?

This approach is not using modules natively but rather as an interface to the original way.

Does this method work without disadvantages?

[mikomikotaishi]

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.

[Spixmaster]

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 .so or .a.

This is relevant here, https://aur.archlinux.org/packages/cpp-httplib-compiled .

[mikomikotaishi]

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

[yhirose]

@mikomikotaishi, thanks for the fine pull request! It's fantastic, but my concern is that someone needs to update modules/httplib.cppm whenever new external symbols are added or existing symbols are removed/renamed, and it could happen quite often. I am not planning to maintain this file. So if you cannot keep maintaining the file, I am probably not merge it since the file can be easily out-of-date. Is there a way to generate modules/httplib.cppm from httplib.h automatically?

@sum01 @jimmy-park @Tachi107 do you have any thought about this pull request?

[mikomikotaishi]

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 using httplib::NEW_SYMBOL_HERE; into the export namespace httlib { } block, for each new symbol that is added. Do let me know if any more information is needed.

[mikomikotaishi]

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).

[mikomikotaishi]

Anyway, I think this could be one such way of automatically updating the module.

[yhirose]

@mikomikotaishi thanks for the additional explanation. I am ok with the following your suggestion.

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.

We could automatically generate modules/httplib.cppm in a GitHub Actions script when httplib.h is pushed. (I can't accept the way to run a script to update the file manually, since I don't maintain any build systems in this repository. Please see #955 (comment).)

[mikomikotaishi]

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.)

[mikomikotaishi]

I'm not sure why there were failing workflows as I didn't change anything in the core library

[mikomikotaishi]

Never mind, it seems the failing CI is happening upstream too.

[yhirose]

Thanks for adding this GitHub Action. But after further consideration, I now think this process should be done in CMakeLists.txt. You could generate modules/httplib.cppm under this line

cpp-httplib/CMakeLists.txt

Line 216 in 87c2b4e

if(HTTPLIB_COMPILE)

We actually do the similar to generate httplib.h and httplib.cc with split.py and put them in a distribution package. By doing this, we no longer need to keep modules/httplib.cppm in this repository. It will be created on the fly only when necessary.

@sum01 @jimmy-park Is my comment above correct?

[mikomikotaishi]

I think it would be difficult to parse an especially large file without syntax analysis or parsing library. I don't have a lot of experience with this sort of thing, and because the header contains things like method definitions outside of the class it seems to be a very complex task. Then including a C++ parser would require a dependency even for a source generation script which would be additional bloat.

I guess this could be done by attaching to the header file that split.py generates, but I haven't actually seen what that looks like.

As for dynamically generating the module, this was raised before on the Dear ImGui library which currently does something like this. I think this is a bad choice for module API (having a static file is obviously best for consumers to be able to just read it from a distance without additional interaction, i.e. a "what-you-see-is-what-you-get" sort of API), but ultimately as you are in charge I'll look into this if you prefer it.

[mikomikotaishi]

I'm looking more into this and I think if we want to allow CMake to compile the module if it's generated into an "out" directory, we have to force the out directory to be named "out" so that it can be written into the CMakeLists.txt script

[mikomikotaishi]

Anyway @yhirose do you have any opinion on the output directory having a hard-coded name?

[yhirose]

@sum01 @jimmy-park @Tachi107 could you please answer this question?

[Tachi107]

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.

[mikomikotaishi]

@Tachi107 CMake needs to know what the output directory is ahead of time to compile the module. How do you propose to solve this?