Repository structure modernization

Open
#502 11 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Active
Tech stack
cmake, cpp

Research direction

Start by reading hll/CMakeLists.txt and the per-sketch include and test CMakeLists files mentioned in the issue. Trace which headers are installed and how test discovery is repeated, then compare the proposed include layouts and detail directories with current consumers. Done means the project agrees on a destination and migration scope before implementation begins.

Written by the indexing model from the issue text.

Description

We'd like to discuss two friction points in the repo layout, both about the public include surface. Filing as a discussion because any change here would break the public API and warrant a major version bump; better to agree on the destination before anyone writes a patch.

Problem 1: Generic top-level header names collide across libraries

Public headers sit at shallow paths with generic filenames, installed flat under a single directory:

hll/include/hll.hpp
theta/include/theta_sketch.hpp
common/include/serde.hpp
common/include/optional.hpp
# ...installed via `DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/DataSketches"`

Consumers write #include <hll.hpp>. Nothing in the path identifies the library, and names like hll.hpp, serde.hpp, optional.hpp, and tdigest.hpp are plausible choices for any number of unrelated projects. A consumer linking against datasketches alongside another library that also ships an hll.hpp ends up with two headers competing for the same include path, with no clean way to disambiguate.

The fix is to namespace the include path under the library name. Two shapes are worth considering.

Option A: Nested per-sketch directories, drop the filename prefix
include/datasketches/
  hll/
    sketch.hpp                 # was hll.hpp
    detail/...
  theta/
    sketch.hpp                 # was theta_sketch.hpp
    union.hpp                  # was theta_union.hpp
    intersection.hpp
    a_not_b.hpp
    jaccard_similarity.hpp
    detail/...
  cpc/
    sketch.hpp
    detail/...
  ...

Consumer: #include <datasketches/theta/union.hpp>

The directory does the namespacing work; the filename drops the now-redundant theta_ prefix. Matches Boost (<boost/graph/adjacency_list.hpp>).

Option B: Flat namespace, keep descriptive filenames
include/datasketches/
  hll_sketch.hpp                # was hll.hpp
  theta_sketch.hpp
  theta_union.hpp
  theta_intersection.hpp
  theta_a_not_b.hpp
  theta_jaccard_similarity.hpp
  cpc_sketch.hpp
  ...
  detail/
    hll/...
    theta/...

Consumer: #include <datasketches/theta_union.hpp>

The filename prefix carries the grouping, and the public surface stays on a single flat level. Matches Abseil (<absl/container/flat_hash_map.h>).

Either way, the install path becomes ${CMAKE_INSTALL_INCLUDEDIR}/datasketches/.

Problem 2: Public and internal headers live in the same directory

hll/include/ mixes the public hll.hpp with roughly 30 implementation headers (e.g. HllSketchImpl.hpp, AuxHashMap.hpp) plus another 15-odd *-internal.hpp files. All of them get installed by hll/CMakeLists.txt. From a consumer standpoint, this seems valid:

#include <DataSketches/HllSketchImpl.hpp>
#include <DataSketches/AuxHashMap-internal.hpp>

There is no clear API boundary between public and internal headers.

The fix is a per-sketch detail/ subdirectory, a convention Boost has used since the early 2000s and that Abseil mirrors with its internal/ directories. Implementation headers move there, and the contract for consumers is straightforward: anything inside detail/ is internal, and reaching in is at your own risk.

Low-priority items

  • Header guards. Two styles coexist: hll/include/HllArray.hpp uses _HLLARRAY_HPP_ (leading underscore, reserved by the standard); theta/include/theta_sketch.hpp uses THETA_SKETCH_HPP_. Switching all headers to #pragma once removes the inconsistency, the reserved-identifier risk, and a class of copy-paste mistakes.
  • No .clang-format. Style is enforced by convention only. Committing a single file would replace formatting back-and-forth in code review.
  • Pick one casing convention. File names and code currently mix CamelCase and snake_case. Low-priority but easy on the eyes.
  • Tests scattered per-sketch. Each <sketch>/test/CMakeLists.txt repeats the Catch2 wiring and test-discovery setup. Consolidating into a single test/ tree (with per-sketch subdirs) would declare the test framework once, give shared fixtures (random key generators, serde helpers) an obvious home. The current setup works; this is cleanup, not a fix.
Dominant language
C++
Stars
273
Forks
88
Avg merge
1d 19h
Merged PRs (30d)
9

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/datasketches-cpp

All issues in apache/datasketches-cpp

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.