Make cmake-based builds faster by being less header-only.

[dimacurrentai]

As cmake-based Current builds are taking off, here's the vision I propose:

1. Keep C5T/Current backwards-compatible with header-only projects, and
2. Minimize one-line-change build times for cmake-based builds.

In simple words, (1) means that just g++ my_code.cc should "just" work if it #include-s the Current headers it needs, since Current remains header-only by design.

Then, (2) is about adding logic under #ifdef-d sections and into the CMakeLists.txt file, so that incremental cmake-based builds are faster. There's C5T_CMAKE_PROJECT already to #ifdef on.

The definition of done is exactly the above:

• The code that uses Current builds & runs fine in both header-only and cmake-first setups, and
• Incremental rebuilds, especially one-line-changes, are much after for the projects that use cmake.

There are several components that could benefit from this approach. Color-coded into green, blue, and orange, and loosely in the order of { "the value it would bring" * "how hard it is" }, they would be:

• The Gnuplot binding. [green]
  • This would be rather streightforward, and is mostly a test / proof-of-concept that the approach works.
• The WaitableAtomic. [green]
  • Uncertain how much win this can generate in terms of time saved, but WaitableAtomic is big.
• The HTTP server. [blue]
  • This likely is the major low-ish-hanging fruit.
• The HTTP client. [green]
  • Another low-ish-hanging fruit too, but not sure we need it that much.
• The type system / serialization library. [orange]
  • This is the major slowdown with builds, BUT: it's not easy to handle.
  • TL;DR: Will need two-phase builds, i.e. protoc-style.
  • I personally believe there exists a clean way that keeps CURRENT_STRUCT-s quick to build, while taking out everything related to reflection and serialization our, autogen-implemented per type.
  • But this is a lot of work, including testing, hence [orange].
• Fix googletest integration. [green]
  • Have our -with-main.h header behave better when built with cmake.
  • Also, fix (or remove) the "cmake test" that compares header-only googletest with the "external one". Probably need a more expensive test, plus some other #define to disable this "fast" behavior.
• The GraphViz binding. [green]
  • Also rather straightforward, but, pragmatically speaking, far less useful than Gnuplot.
• And, definitely last: the Current Storage. [orange]
  • This is at least as hard as CURRENT_STRUCT-s, but more difficult.
  • Our storage relies heavily on type evolution, which may well be super tricky.
  • Also uncertain how useful this is, since (personally) I would only use our storage if it's mature enough and flexible enough, which it is not.
  • Also, Current's storage may well be something we decide to not keep backwards-compatible with the header-only setup.
  • Also, LevelDB intergration might come in handy here.
  • Also, JSONs are a bit too slow for storage's purposes, so perhaps build binary formats first?

In the list above [green] is a piece of cake, [blue] is "doable, but requires quite some Current-specific context, and [orange] is literally "someone has a lot of time to kill / invest".

Not sure how much time I will have in the coming months, but I'd like to have this written down somewhere, and a GitHub issue sounds good. We'll close/resolve it as soon as any real work begins, and/or if we choose to re-prioritize. Also, nothing prevents us from editing this message, although I'd prefer to keep it as is due to my personal preference of tracking things fairly.

Last but not least: the Educational Designs section of the SysDesign Meetup README page outlines a few principles which Current may well follow, since, who knows, some of those designs I keep planning to materialize could be Current-first.

Thanks,
Dima

[dimacurrentai]

@mzhurovich WDYT?