Distribution, packaging

[friendlyanon]

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

• Have a package for every dependency:
  • double-conversion (https://repology.org/project/double-conversion/versions)
  • jtckdint (https://repology.org/projects/?search=jtckdint)
    Vendored source diverges from upstream since 60a4a04
• Decide on a binary artifact/package name (jt-json-cpp? jsoncpp is "taken" https://vcpkg.link/ports/jsoncpp)
• Decide on static-only or static/shared (requires export macros)
• CMake (optional, but would make cross-platform easier and I volunteer to make a PR)

[jart]

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]

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]

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]

+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]

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: jart/jtckdint@6764e17#commitcomment-149115155

[jart]

@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]

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]

OK we now have:

• A cmake build config
• CI runners for
  • Ubuntu x86
  • Ubuntu aarch64
  • Ubuntu ppc64le
  • Ubuntu s390x
  • MacOS
  • MSVC
  • MSYS2

[aozgaa]

One thing I noticed is that there's no guard to BUILD_TESTS or similar, so when importing this package with, eg, CPM.cmake, the tests are built and some effort needs to be taken to exclude them from running[1]. The tests fail because they assume a relative directory structure for JSONTestSuite/, which (understandably) isn't install()d.

This may very well be out-of-scope, but thought it worth mentioning.

[1] In my case, I added a patch to delete all CMakeLists.txt lines related to testing to my "add package" statement.

[Waqar144]

One thing I noticed is that there's no guard to BUILD_TESTS or similar, so when importing this package with, eg, CPM.cmake, the tests are built and some effort needs to be taken to exclude them from running[1]. The tests fail because they assume a relative directory structure for JSONTestSuite/, which (understandably) isn't install()d.

@aozgaa This should be fixed with #15 I believe