create a header-only version

[nlohmann]

As wished in http://www.reddit.com/r/cpp/comments/2rbhn3/json_for_modern_c_what_if_json_was_part_of_modern/cnelnzq:

I think this would be fare more useful as a header only library. I'm down for sending a PR with the change if you are.

And as I wrote:

Good idea! But I think it would be more useful if there would be a script that reads the source files json.cc and json.h and creates a header-only version. That way, both approaches can be followed at the same time.

[hrobeers]

Or people can just include the cpp file.
I don't really see the advantage of making it header only.

[PaulFreund]

It can improve compile time when precompiled headers are used and allows easy include only usage. The cpp file always has to be supplied to the compiler (which is mostly done by build tools that assume everything in one root) and therefore encourages adding the source directly in projects instead of just pulling them from a central include path.

Unfortunatly the cpp world has no ultimate solution to dependencies, packaging, etc. so I don't know if this is an advantage for others.

[daminetreg]

Have you already seen biicode ? They are really active in bringing a dependency solution for C++.

[PaulFreund]

I've seen it and it seems pretty cool, but I don't want to rely on proprietary tools. I couldn't find a statement about escrow or plans for worst case.

[nlohmann]

@PaulFreund - could you check if the file header_only/json.h suits your needs?

[Teemperor]

Should we really push the generated header only version to the repository? It's a generated file similar to a binary and should be hosted somewhere else.

[nlohmann]

I thought about it and thought the way Catch are doing it is reasonable. In the end, creating the header requires tools such as cat and sed. While they may be standard on some machines, they are not for Windows. Once the code is reasonably stable, one could think about using GitHub's release feature.

@Teemperor, what do you think?

[Teemperor]

I think a release on Github from time to time is the best solution right now. It's just slightly more work compared to pushing the header file to git and it keeps the repository clean.

If we want this automated, we could also just run the header generation on a external server and serve it over HTTPS (or use the Github API to create releases).

[nlohmann]

Apart from the issue of how to publish the header-only version, I think we are done here.

[PaulFreund]

Sorry for the late reply. Unfortunately just copying header and source together won't be enough. While free functions could be inlined, the member functions that are defined outside of their class declarations can't.

From my point of view there are only upsides for developing the library completely header only but I understand that it might also be a matter of taste.

[nlohmann]

Thanks @PaulFreund for your reply.

As I have no experience in creating a header-only version, I assumed that copying the sources would be enough. Can you give me more insights why this is not sufficient or point me to sources that explain how to do this properly?

[Zoadian]

you'll get duplicated symbols if you include it more than once

[nlohmann]

You are right. I did not check for a case where the header is included in several files. :-(

[danpolanco]

👍 for header only version.

[cdaylward]

👍 for header-only version. I'm very happy with this library but I had to do my own temporary patching (inlining) so that I could use it in my own header-only libraries.

[nlohmann]

Fixed in latest commit: the class is now header-only.

[danpolanco]

👏