search

jart / json.cpp

JSON for Classic C++
Other
635 stars 18 forks source link

Distribution, packaging #3

Open friendlyanon opened 1 week ago

friendlyanon commented 1 week ago

This is more of a TODO list to make the project distributable:

jart commented 1 week ago

Originally the intent was to just provide something simple that people can copy into their codebases and change to taste. We could however do this too. In that case you're right we probably want a better name. How about jart::Json for that? Then use jart-json as the package name? We could potentially avoid a namespace by calling the class JtJson and then using jtjson as the vcpkg name. I think I'm leaning towards jtjson.

I have vcpkg installed on my computer, but I've never used it before. Once we pick a name and add the necessary configs, if you tell me what commands I need to run to register the package, I'll do it.

Both shared and static are fine.

If you send a PR with a cmake config and write a github action that runs it, I'll merge it and maintain it.

friendlyanon commented 1 week ago

Sounds good to me. I can start with creating a package for jtckdint.

Are you sure about providing/enabling a shared library? That will require the aforementioned export macros, SO version management to denote ABI changes and the usual shared library stuff.
With the size of the code, I don't think only a static library would be much of a waste in terms of space.

jart commented 1 week ago

Let me do the registration. You don't want to own the maintenance burden for my projects.

Good point. How about we start with only static? I assume we can always do shared later on. It's better to give contributors more freedom in the beginning to change things, wouldn't you agree?

valgur commented 1 week ago

+1. I would love to add it as a package on ConanCenter as well.

Regarding adding shared library support - you can start out simple and only support non-Windows platforms initially, which don't require export macros, and soname versioning can be tackled later as well (although adding it in CMake is as simple as setting a SOVERSION property on the library).

friendlyanon commented 1 week ago

only support non-Windows platforms initially, which don't require export macros

Yes, you very much do if you follow platform guidelines: https://gcc.gnu.org/wiki/Visibility
But before any of that, jtckdint needs attention first: https://github.com/jart/jtckdint/commit/6764e17814750839dec1f4cc41f7be0ddcae6449#commitcomment-149115155

jart commented 5 days ago

@friendlyanon Thanks for discovering __SIZEOF_INT128__. That works back to at least GCC 4.8. We'll get that merged today.

@valgur I'm happy to support that package manager too. Would it be possible for me to automate this work GitHub Actions? If you could get me setup with a PR that automates publishing there, then I'll commit myself to maintaining it going forward.

friendlyanon commented 5 days ago

Conan and vcpkg are both centralized by default. Conan uses Conan Center Index and vcpkg uses the git repo it comes with by default. Packaging something for either requires submitting a recipe (Conan) or a port (vcpkg). This requires a PR with someone reviewing and merging that. There is no automatic package creation you can script with GitHub Actions.

jart commented 5 days ago

OK we now have: