Explicitly discuss cmkr's value proposition

[mrexodia]

This was a comment on hacker news a while back:

I think Cmkr fails to state its value proposition by focusing on how it works.

Any system like CMake that wraps boatloads of complexity is going to have unexpected interactions and inscrutable failures.

The question for any developer who doesn't want to become a build system guru is whether they can take a happy path far from any gotcha's.

That's when people start defining conventions to solve classes of problems: follow this template to do X, and you'll be fine.

The value of Cmkr lies in being about to define those conventions and happy paths. I should be able to inspect their templates, and if one fits, I'm good to go.

Even nicer would the ability to retrofit my build to a known-working template.

But Cmkr only presents the "beginners" template repo as an aside, and says nothing about whether these templates are tested for various projects on various systems.

By not explicitly identifying the problem it's trying to solve, Cmkr seems to have bumped up against a solution accidentally, and doesn't give me confidence. I believe that could be easily remedied.

This is a very valid criticism. Cmkr is being developed to solve real problems, but the documentation is lacking when it comes to explicitly stating them (mainly because I spend all my time actually using and improving it, not writing documentation).

Claude:

Based on these comments, here's how I would address the main criticisms and concerns about cmkr:

1. Value Proposition

   • Clearly state that cmkr is not trying to be another build system layer, but rather a declarative interface to CMake
   • Emphasize that it aims to simplify common CMake usage patterns through TOML configuration while maintaining full CMake compatibility
   • Focus on the specific problems it solves: reducing boilerplate, improving readability, and making CMake more approachable

2. Address the "wrapper" criticism

   • Acknowledge that adding layers can be problematic, but explain that cmkr generates standard CMake files directly
   • Emphasize that it's not an opaque layer - users can always inspect the generated CMake code
   • Highlight that it's self-bootstrapping and doesn't require additional runtime dependencies

3. Scope and Limitations

   • Be upfront about what cmkr can and cannot do
   • Clearly document the supported CMake features
   • Provide guidance on when users might need to fall back to raw CMake
   • Show examples of how to integrate custom CMake code when needed

4. Documentation Improvements

   • Add more real-world examples and use cases
   • Document common patterns and best practices
   • Provide clear migration paths from existing CMake projects
   • Include troubleshooting guides for common issues

5. Testing and Reliability

   • Document which scenarios and platforms are tested
   • Provide example templates that are verified to work across different environments
   • Include integration tests with various build configurations

The key is to position cmkr as a pragmatic tool that simplifies common CMake workflows while being transparent about its limitations and maintaining compatibility with existing CMake functionality.