FloofyPlasma/smelt

Smelt is aiming at a painful gap in the C ecosystem: small projects often outgrow raw compiler commands, but adopting a full build system can feel heavier than the project itself. The appeal here is that Smelt gives C developers a single manifest file, predictable profiles, dependency recipes, lockfile behavior, and editor tooling output without forcing the project to become more complicated than the code it is building.

What makes the repo interesting is that the author is already building toward a real package and build workflow rather than a thin wrapper around cc. The source layout separates commands, project handling, package logic, and core utilities, which makes the intent readable. Features like incremental hashing, pkg config support, registry recipes, vendored dependencies, lockfiles, and compile_commands.json output show that the project is confronting real build system complexity early.

The strongest part of Smelt is the shape of the idea. C tooling often makes developers choose between bare compiler commands, Makefiles that grow into private languages, or larger systems that feel detached from the simplicity of the project. Smelt is trying to offer a smaller path: one project file, one build command, profile aware builds, dependency resolution, and enough metadata generation to work with modern editors. That is a useful niche.

The main issue is trust maturity. There appears to be a serious build command issue where failed builds may still return exit code 0. For a build tool, that is critical because CI and shell scripts depend on correct exit status. Object files also appear to be derived from source basenames, which can cause collisions when different folders contain files with the same name. compile_commands.json generation is manually written and marked with TODOs for cleanup and proper C++ support. Registry fetching would also benefit from stricter HTTP failure handling.

The adoption gap is verification. A build tool needs boring confidence. Users need to know that manifest parsing, dependency resolution, cache invalidation, profile selection, lockfile behavior, C and C++ handling, platform specific paths, and editor metadata keep working as the project changes. Even a small CI workflow that bootstraps Smelt, builds the test fixture, checks incremental rebuild behavior, and validates compile_commands.json would make the project much easier to trust.

Overall: strong concept, real architecture, but still prototype grade reliability. Fix exit codes, add CI and tests, harden registry fetches, preserve source relative object paths, and document the registry format more clearly. With those pieces in place, Smelt could become a genuinely useful lightweight build tool for C projects.

Smelt is a promising early-stage tool with a clear purpose: making C projects feel closer to Cargo-style workflows without forcing users into a heavyweight build system. The README does a good job setting expectations by calling the project work-in-progress, while still showing enough real functionality to make the idea concrete: smelt.toml, debug/release profiles, incremental content hashing, lockfile support, registry dependencies, pkg-config dependencies, and compile_commands.json generation.

What stood out most is that the repo is already organized like a real tool rather than a throwaway prototype. The split between src/cmd, src/core, src/pkg, and src/project makes the responsibilities legible, and files like manifest.c, build.c, resolve.c, and depbuild.c suggest the project is tackling the hard parts directly instead of only wrapping cc. The self-hosting smelt.toml is also a nice touch because it demonstrates the format on the project itself. Including .clang-format, .clang-tidy, an MIT license, vendored parser/hash/getopt dependencies, and recent signed commits all make the repository feel cared for.

The main adoption gap is verification. There is a testlib fixture, but no visible test command yet, no CI workflow, and the roadmap still lists smelt test and parallel compilation as unfinished. For a build tool, confidence matters a lot: users need to know manifest parsing, dependency resolution, cache invalidation, profile selection, C/C++ handling, and platform-specific process/filesystem behavior keep working as changes land. Even a small GitHub Actions workflow that bootstraps smelt, runs it against testlib, checks incremental rebuild behavior, and validates compile_commands.json would make the project much easier to trust. The open issue about builds no longer being parallel is also worth either fixing or documenting as a known regression, since “fast” is part of the core pitch.

I’d also expand the README with one full sample smelt.toml, expected output layout, supported platforms, and a short explanation of the registry format. Right now the project is interesting and technically credible, but a new user still has to infer a lot from the source. A little more documentation plus basic CI would make Smelt much easier for C developers to try seriously.