Updating cmake config to support publication and package building

[will-lauer]

A bunch of cmake changes to improve a bunch of things:

• Add missing files
• enable package building
• enable cmake structure to support importing with find_package

[coveralls]

Pull Request Test Coverage Report for Build 1355799137

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+5.2%) to 97.93%

---

Totals
Change from base Build 1317592223:	5.2%
Covered Lines:	7427
Relevant Lines:	7584

---

💛 - Coveralls

[jmalkin]

A couple questions but nothing that's a blocker.

Installing all files into a single directory makes me think we need to revisit file naming for a few sketches. Mostly HLL (which is my fault).

[jmalkin]

PRIVATE seems to be spaced way over for some reason?

[will-lauer]

Looks like this spacing is because I use 4-space tabs in my editor. The file is a bit of a mix between tabs and spaces (and some of that is my fault), with tab seeming to be the default. It looks like git is showing the data using 8-space tabs, which makes it line up differently than in my editor.

[AlexanderSaydakov]

I would prefer spaces for consistency, but this is not critical

[jmalkin]

Should we provide the set (of size 1, I think?) of exported variables somewhere?

I guess related, do we want to expose the individual sketches or just have people depend on the entire library? I think it'll only pull in relevant files since we're header-only.

[will-lauer]

Yes, a list of the environment variables is likely useful in the doc. In fact, it should probably be expanded to more than one, as both include directory, library, and target are useful.

[will-lauer]

In response you @jmalkin's single directory comment, the files are named such that there are no collisons right now, but I suspect that restructuring the install image so that there is a toplevel datasketches directory that contains separate directories for each individual sketch type, plus a common directory, would be a better layout. Unfortunately, that has a fairly high impact, as it potentially changes the #include statements both in the code and in client code.