7 ms·

Show HN: I built a Cargo-like build tool for C/C++

177 points by randerson_112 6mo ago

I love C and C++, but setting up projects can sometimes be a pain. Every time I wanted to start something new I'd spend the first hour writing CMakeLists.txt, figuring out find_package, copying boilerplate from my last project, and googling why my library isn't linking. By the time the project was actually set up I'd lost all momentum. So, I built Craft - a lightweight build and workflow tool for C and C++. Instead of writing CMake, your project configuration goes in a simple craft.toml: [project] name = "my_app" version = "0.1.0" language = "c" c_standard = 99 [build] type = "executable" Run craft build and Craft generates the CMakeLists.txt automatically and builds your project. Want to add dependencies? That's just a simple command: craft add --git https://github.com/raysan5/raylib --links raylib craft add --path ../my_library craft add sfml Craft will clone the dependency, regenerate the CMake, and rebuild your project for you. Other Craft features: craft init - adopt an existing C/C++ project into Craft or initialize an empty directory. craft template - save any project structure as a template to be initialized later. craft gen - generate header and source files with starter boilerplate code. craft upgrade - keeps itself up to date. CMakeLists.extra.cmake for anything that Craft does not yet handle. Cross platform - macOS, Linux, Windows. It is still early (I just got it to v1.0.0) but I am excited to be able to share it and keep improving it. Would love feedback. Please also feel free to make pull requests if you want to help with development!

deleted 6mo ago
[deleted]
wg0 6mo ago
Yesterday I had to wrestle with CMake. But how this tool figures out where the header files and build instructions for the libraries are that are included? Any expected layout or industry wide consensus?
- integricho 6mo ago
  I believe it supports only projects having a working cmake setup, no extra magic
- flohofwoe 6mo ago
  I suspect it depends on a specific directory structure, e.g. look at this generated cmake file: https://github.com/randerson112/craft/blob/main/CMakeLists.txt https://github.com/randerson112/craft/blob/main/CMakeLists.t... ...and for custom requirements a manually created CMakeLists.extras.txt as escape hatch. Unclear to me how more interesting scenarios like compiler- and platform-specific build options (enable/disable warnings, defines, etc...), cross-compilation via cmake toolchain files (e.g. via Emscripten SDK, WASI SDK or Android SDK/NDK) would be handled. E.g. just trivial things like "when compiling for Emscripten, include these source files, but not those others".
- eliemichel 6mo ago
  CMakes piles up various generations of idioms so there are multiple ways of doing it, but personally I’ve learned to steer away from find_package() and other magical functions. Get all your dependencies as subdirectories (whichever way you prefer) and use add_subdirectory(). Use find_package() only in so-called "config" mode where you explicitly instruct cmake where to find the config for large precompiled dependencies only
  - mathstuf 6mo ago
    FD: I am a CMake developer. Yes, config packages are better. But I think doing find_package everywhere is better. Assuming you install an SDK for others to use your project. If you're a "product", vendor away. The issue comes when you want to vendor X and Y and both vendor Z independently. Then you're stuck de-vendoring at least one and figuring out how to provide it yourself internally. IMO, better to just let Z make its own install tree and find it as a package from there. One can write good Find modules, but there is some "taste" involved. I wish we had more good examples to use as templates.
duped 6mo ago
FWIW: there is something fundamentally wrong with a meta-meta build system. I don't think you should bother generating or wrapping CMake, you should be replacing it.
- SpaceNoodled 6mo ago
  My thoughts exactly. I thought this was going to be some new thing, but it's just yet another reason that I'll stick with Makefiles.
  - flohofwoe 6mo ago
    Do your Makefiles work across Linux, macOS and Windows (without WSL or MingW), GCC, Clang and MSVC, or allow loading the project into an IDE like Xcode or Visual Studio though? That's why meta-build-systems like cmake were created, not to be a better GNU Make.
    - uecker 6mo ago
      There is something fundamentally wrong with Windows or Visual Studio that it requires ugly solutions.
      - delta_p_delta_x 6mo ago
        Windows and Visual Studio solutions are perfectly fine. MSBuild is a declarative build syntax in XML, it's not very different from a makefile.
        uecker 6mo ago
        XML is already terrible. But the main problem seems to be that they created something similar but incompatible to make.
      - flohofwoe 6mo ago
        Ok, then just cl.exe instead of gcc or clang. Completely different set of command line options from gcc and clang, but that's fine. C/C++ build tooling needs to be able to deal with different toolchains. The diversity of C/C++ toolchains is a strength, not a weakness :) One nice feature of MSVC is that you can describe the linker dependencies in the source files (via #pragma comment(lib, ...)), this enables building fairly complex single-file tools trivially without a build system like this: cl mytool.c ...without having to specify system dependencies like kernel32 etc... on the cmdline.
mc-serious 6mo ago
[flagged]
flohofwoe 6mo ago
Heh, looks like cmake-code-generators are all the rage these days ;) Here's my feeble attempt using Deno as base (it's extremely opinionated though and mostly for personal use in my hobby projects): https://github.com/floooh/fibs https://github.com/floooh/fibs One interesting chicken-egg-problem I couldn't solve is how to figure out the C/C++ toolchain that's going to be used without running cmake on a 'dummy project file' first. For some toolchain/IDE combos (most notably Xcode and VStudio) cmake's toolchain detection takes a lot of time unfortunately.
- apparatur 6mo ago
  I'm intrigued by the idea of writing one's own custom build system in the same language as the target app/game; it's probably not super portable or general but cool and easy to maintain for smaller projects: https://mastodon.gamedev.place/@pjako/115782569754684469 https://mastodon.gamedev.place/@pjako/115782569754684469
deleted 6mo ago
[deleted]
lgtx 6mo ago
The installation instructions being a `curl | sh` writing to the user's bashrc does not inspire confidence.
- jjgreen 6mo ago
  [flagged]
  - Bjartr 6mo ago
    If you'd just left off "to fuck" you'd end up way less downvoted, if it even happened at all.
    - KPGv2 6mo ago
      [flagged]
      - jvanderbot 6mo ago
        Knowing the reason something is considered bad does not immediately change that fact that it is considered bad. Social / emotional signals still exist around that word.
    - jjgreen 6mo ago
      With fucks, without fucks, in iambic pentameter, anything vaguely critical of Rust will be downvoted. As you can see.
    - account42 6mo ago
      Probably not. This isn't prime time TV, some foul language is tolerated - but complaining about down-votes, especially preemptively, has a predictable response (IMO rightfully so).
      - jjgreen 6mo ago
        No complaints about down votes, simply warning the OP that (s)he will be getting some. Personally I quite like them, they indicate that I've irritated a Rust evangelist; that gives me a warm feeling inside.
spwa4 6mo ago
Just switch to bazel, copy my hermetic build config and just use it ... yes, you can hate me know.
cherryteastain 6mo ago
Seems to solve a problem very similar to Conan or vcpkg but without its own package archive or build scripts. In general, unlike Cargo/Rust, many C/C++ projects dynamically link libraries and often require complex Makefile/shell script etc magic to discover and optionally build their dependencies. How does craft handle these 'diamond' patterns where 2 dependencies may depend on versions of the same library as transitive dependencies (either for static or dynamic linking or as header-only includes) without custom build scripts like the Conan approach?
Surac 6mo ago
Uses CMAKE, Sorry not for me. Call me old but i prefere good old make or batch. Maybe it's because i can understand those tools. Debugging CMAKE build problems made me hate it. Also i code for embedded CPU and most of the time CMAKE is just overkill and does not play well the compiler/binutils provided. The Platform independency is just not happening in those environments.
- bluGill 6mo ago
  For simple projects. Make is easier for simple things I will grant. However when your projects gets complex at all make becomes a real pain and cmake becomes much easier. Cmake has a lot of warts, but they have also put a lot of effort into finding and fixing all those weird special cases. If your project uses CMake odds are high it will build anywhere.
  - tosti 6mo ago
    Odds are high the distro maintainer will lose hair trying to package it
  - lkjdsklf 6mo ago
    Also, for better or worse, cmake is pretty much the "standard" for C/C++ these days. Fighting the standard often creates it's own set of problems and nightmares that just aren't worth it. Especially true in C++ where yhou often have to integrate with other projects and their build systems. Way easier if you just use cmake like everyone else. Even the old hold outs, boost and google open source, now use cmake for their open source stuff.
- delta_p_delta_x 6mo ago
  > most of the time CMAKE is just overkill and does not play well the compiler/binutils provided You need to define a CMake toolchain[1] and pass it to CMake with --toolchain /path/to/file in the command-line, or in a preset file with the key `toolchainFile` in a CMake preset. I've compiled for QNX and ARM32 boards with CMake, no issues, but this needs to be done. [1]: https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html https://cmake.org/cmake/help/latest/manual/cmake-toolchains....
looneysquash 6mo ago
Nice. I have been thinking of making something similar. Now hopefully I don't have to! Not sure how big your plans are. My thoughts would be to start as a cmake generator but to eventually replace it. Maybe optionally. And to integrate suppoet for existing package managers like vcpkg. At the same time, I'd want to remain modular enough that's it's not all or nothing. I also don't like locking. But right now package management and build system are decoupled completely. And they are not like that in other ecosystems. For example, Cmake can use vcpkg to install a package but then I still have to write more cmake to actually find and use it.
- psyclobe 6mo ago
  > For example, Cmake can use vcpkg to install a package but then I still have to write more cmake to actually find and use it. I have this solved at our company. We have a tool built on top of vcpkg, to manage internal + external dependencies. Our cmake linker logic leverages the port names and so all you really do is declare your manifest file (vcpkg.json) then declare which one of them you will export publicly. Everything after that is automatic including the exported cmake config for your library.
tombert 6mo ago
This certainly seems less awful than the typical C building process. What I've been doing to manage dependencies in a way that doesn't depress me much has been Nix flakes, which allows me a pretty straightforward `nix build` with the correct dependencies built in. I'm just a bit curious though; a lot of C libraries are system-wide, and usually require the system package manager (e.g. libsdl2-dev) does this have an elegant way to handle those?
- randerson_112 6mo ago
  Yes, many libraries are system wide that is true. This is something I had on the list of features to add. System dependencies. Thank you for the feedback!
mococa 6mo ago
Compared to Conan, what are the advantages?
- randerson_112 6mo ago
  Craft has project management and generates starter project structure. You can generate header and source files with boilerplate starter code. Craft manages the building of the project so you don’t need to write much CMake. You can also save project structures as templates and instantiate those templates in new projects ready to go.
  - mococa 6mo ago
    How you can be better than CMake?
bluGill 6mo ago
Anyone can make a tool that solves a tiny part of the problem. however the reason no such tool has caught on is because of all the weird special cases you need to handle before it can be useful. Even if you limit your support to desktop: OS/X and Windows that problem will be hard, adding various linux flavors is even more difficult, not to mention BSD. The above is the common/mainstream choices, there Haiku is going to be very different, and I've seen dozens of others over the years, some of them have a following in their niche. Then there are people building for embedded - QNX, vxworks, or even no OS just bare metal - each adding weirdness (and implying cross compiling which makes everything harder because your assumptions are always wrong). I'm sorry I have to be a downer, but the fact is if you can use the word "I" your package manager is obviously not powerful enough for the real world.
- the__alchemist 6mo ago
  I will categorize this as a pattern I've seen which leads to stagnation, or is at least aiming for it. Usually these are built on one or more assumption which doesn't hold. The flow of this pattern: - Problem exists - Proposals of solutions, (varying quality), or not - "You can't just solve this. It's complicated! This problem must exist". (The post I'm replying to - Problem gets solved, hopefully. Anecdotes I'm choosing based on proximity to this particular problem: uv and cargo. uv because people said the same thing about python packaging, and cargo because its adjacent to C and C++ in terms of being a low-level compiled language used for systems programming, embedded/bare-metal etc. The world is rich in complexity, subtlety, and exceptions to categorization. I don't think this should block us from solving problems.
  - bluGill 6mo ago
    I didn't say the problem couldn't be solved. I said the problem can't be solved by one person. There is a difference. (maybe it can be solved by one person over a few decades)
    - tekne 6mo ago
      I mean -- if I'm going to join a team to solve the hard 20%, I'd like to see the idea validated against the easy 80% first. If it's really bad, at least the easy 20%.
seniorThrowaway 6mo ago
Having to work around a massive C++ software project daily, I wish you luck. We use conan2, and while it can be very challenging to use, I've yet to find something better that can handle incorporating as dependencies ancient projects that still use autoconf or even custom build tooling. It's also very good at detecting and enforcing ABI compatibility, although there are still some gaps. This problem space is incredibly hard and improving it is a prime driver for the creation of many of the languages that came after C/C++
- mgaunard 6mo ago
  I find that conan2 is mostly painful with ABI. Binaries from GCC are all backwards compatible, as are C++ standard versions. The exception is the C++11 ABI break. And yet it will insist on only giving you binaries that match exactly. Thankfully there are experimental extensions that allow it to automatically fall back.
gavinray 6mo ago
The least painful C/C++ build tool I've used is xmake https://github.com/xmake-io/xmake https://github.com/xmake-io/xmake The reason why I like it (beyond ease-of-use) is that it can spit out CMakeLists.txt and compile_commands.json for IDE/LSP integration and also supports installing Conan/vcpkg libraries or even Git repos. set_project("myapp") set_languages("c++20") add_requires("conan::fmt/11.0.2", {alias = "fmt"}) add_requires("vcpkg::fmt", {alias = "fmt"}) add_requires("git://github.com/fmtlib/fmt v11.0.2", {alias = "fmt"}) target("myapp") set_kind("binary") add_files("src/*.cpp") add_packages("fmt") Then you use it like # Generate compile_commands.json and CMakeLists.txt $ xmake project -k compile_commands $ xmake project -k cmake # Build + run $ xmake && xmake run myapp
- delta_p_delta_x 6mo ago
  Agreed, xmake seems very well-thought-out, and supports the most modern use-cases (C++20 named modules, header unit modules, and `import std`, which CMake still has a lot of ceremony around). I should switch to it.
- ethin 6mo ago
  I would happily switch to it in a heartbeat if it was a lot more well-documented and if it supported even half of what CMake does. As an example of what I mean, say I want to link to the FMOD library (or any library I legally can't redistribute as an SDK). Or I want to enable automatic detection on Windows where I know the library/SDK is an installer package. My solution, in CMake, is to just ask the registry. In XMake I still can't figure out how to pull this off. I know that's pretty niche, but still. The documentation gap is the biggest hurtle. A lot of the functions/ways of doing things are poorly documented, if they are at all. Including a CMake library that isn't in any of the package managers for example. It also has some weird quirks: automatic/magic scoping (which is NOT a bonus) along with a hack "import" function instead of using native require. All of this said, it does work well when it does work. Especially with modules.
- IshKebab 6mo ago
  I've had some experience with this but it seems to be rather slow, very niche and tbh I can't see a reason to use it over CMake.
shevy-java 6mo ago
Will take C only 51 years to adopt.
dima55 6mo ago
If you think cmake isn't very good, the solution isn't to add more layers of crap around cmake, but to replace it. Cmake itself exists because a lot of humans haven't bothered to read the gnu make manual, and added more cruft to manage this. Please don't add to this problem. It's a disease
- dymk 6mo ago
  As much of a dog as cmake is, "just use make!" does not solve many of the problems that cmake makes a go at. It's like saying go write assembler instead of C because C has so many footguns.
  - dima55 6mo ago
    GNU Make has a debugger. This alone makes it far superior to every other build tool I've ever seen. The cmake debugging experience is "run a google search, and try random stuff recommended by other people that also have no idea how the thing works". This shouldn't be acceptable.
    - beckford 6mo ago
      That hasn't been true for a few years at least. https://www.jetbrains.com/help/clion/cmake-debug.html https://www.jetbrains.com/help/clion/cmake-debug.html is has had CMake debugging since cmake 3.27. Ditto for vscode and probably other C IDEs I am not familiar with. So does Gradle for Java. GNU make is hardly exclusive.
- wiseowise 6mo ago
  I'm all for shitting on CMake, but Jesus, to suggest Make as a replacement/improvement is an unhinged take.
  - dima55 6mo ago
    I'm suggesting that people creating build systems read the make manual. Surely this isn't controversial?
mutkach 6mo ago
Please consider adding `cargo watch` - that would be a killer feature!
- randerson_112 6mo ago
  Yes! This is definitely on the list of features to add. Thank you for the feedback!
looneysquash 6mo ago
Besides Cargo, you might want to take a look at Python's pyproject.toml standard. https://packaging.python.org/en/latest/guides/writing-pyproject-toml/ https://packaging.python.org/en/latest/guides/writing-pyproj... It's similar, but designed for an existing ecosystem. Cargo is designed for `cargo`, obviously. But `pyproject.toml` is designed for the existing tools to all eventually adopt. (As well as new tools, of course.)
kjksf 6mo ago
In the age of AI tools like this are pointless. Especially new ones, given existence of make, cmake, premake and a bunch of others. C++ build system, at the core, boils down to calling gcc foo.c -o foo.obj / link foo.obj foo.exe (please forgive if I got they syntax wrong). Sure, you have more .c files, and you pass some flags but that's the core. I've recently started a new C++ program from scratch. What build system did I write? I didn't. I told Claude: "Write a bun typescript script build.ts that compiles the .cpp files with cl and creates foo.exe. Create release and debug builds, trigger release build with -release cmd-line flag". And it did it in minutes and it worked. And I can expand it with similar instructions. I can ask for release build with all the sanitize flags and claude will add it. The particulars don't matter. I could have asked for a makefile, or cmake file or ninja or a script written in python or in ruby or in Go or in rust. I just like using bun for scripting. The point is that in the past I tried to learn cmake and good lord, it's days spent learning something that I'll spent 1 hr using. It just doesn't make sense to learn any of those tools given that claude can give me working any build system in minutes. It makes even less sense to create new build tools. Even if you create the most amazing tool, I would still choose spending a minute asking claude than spending days learning arbitrary syntax of a new tool.
- duped 6mo ago
  You're missing finding library/include paths, build configuration (`-D` flags for conditional compilation), fetching these from remote repositories, and versioning.
  - jcotton42 6mo ago
    Also other tasks like compiling resource or translation files.
- deleted 6mo ago
  [deleted]
- randerson_112 6mo ago
  This is a fair and valid point. However, why leave your workflow to write a prompt to an AI when you can run simple commands in your workspace. Also you are most likely paying to use the AI while Craft is free and open source and will only continue to improve. I respect your feedback though, thank you!
adev_ 6mo ago
Feedback of someone who is used to manage large (>1500) software stack in C / C++ / Fortran / Python / Rust / etc: - (1) Provide a way to compile without internet access and specify the associated dependencies path manually. This is absolutely critical. Most 'serious' multi-language package managers and integration systems are building in a sandbox without internet access for security reasons and reproducibility reasons. If your build system does not allow to build offline and with manually specified dependencies, you will make life of integrators and package managers miserable and they will avoid your project. (2) Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity. People expect code to be portable and shippable. Good default options should be CMake equivalent of "RelWithDebInfo" (meaning: -O2 -g -DNDEBUG ). -O3 can be argued. -march=native is always always a mistake. - (3) Allow your build tool to be built by an other build tool (e.g CMake). Anybody caring about reproducibility will want to start from sources, not from a pre-compiled binary. This also matter for cross compilation. - (4) Please offer a compatibility with pkg-config (https://en.wikipedia.org/wiki/Pkg-config https://en.wikipedia.org/wiki/Pkg-config) and if possible CPS (https://cps-org.github.io/cps/overview.html https://cps-org.github.io/cps/overview.html) for both consumption and generation. They are what will allow interoperability between your system and other build systems. - (5) last but not least: Consider seriously the cross-compilation use case. It is common in the world of embedded systems to cross compile. Any build system that does not support cross-compilation will be de facto banned from the embedded domain.
- moralestapia 6mo ago
  >15000 15000 what?
  - adev_ 6mo ago
    1500 C/C++ individual software components. The 15000 was a typo on my side. Fixed.
    - moralestapia 6mo ago
      I see, thanks. I didn't mind the number it just wasn't clear what was it about.
nesarkvechnep 6mo ago
As long as it's for C/C++ and not C or C++, I'm skeptical.
- randerson_112 6mo ago
  Why do you say this? I respect it, I'm just curious.
  - avadodin 6mo ago
    C/C++ is HR-newspeak out of the 1990s(at the time it was not clear that anyone would still want to use C and MSVC did move their compiler to C++). It signals that the speaker doesn't understand that the two are different languages with very different communities. I don't really think that C users are entirely immune to dependency hell, if that's what OP meant, though. It is orthogonal. As a user, I do believe it sucks when you depend on something that is not included by default on all target platforms(and you fail to include it and maintain it within your source tree*).
    - unclad5968 6mo ago
      What part of the build process is different for C?
      - avadodin 6mo ago
        I explained why C/C++ rubbed op the wrong way. It has nothing to do with a build process. It is probably true that more average C programs can be built with plain Makefiles or even without a Makefile than C++, though. You can of course add dependencies on configure scripts, m4, cmake, go, python or rust when building a plain self-contained C program and indeed many do.
        unclad5968 6mo ago
        Well the post is about build tools, so I assumed we were talking about that.
einpoklum 6mo ago
Impression before actually trying this: CMake is a combination of a warthog of a specification language, and mechanisms for handling a zillion idiosyncracies and corners cases of everything. I doubt than < 10,000 lines of C code can cover much of that. I am also doubtful that developers are able to express the exact relations and semantic nuances they want to, as opposed to some default that may make sense for many projects, but not all. Still - if it helps people get started on simpler or more straightforward projects - that's neat :-)
randerson_112 6mo ago
Thank you everyone for the feedback so far! I just wanted to say that I understand this is not a fully cohesive and functional project for every edge case. This is the first day of releasing it to the public and it is only the beginning of the journey. I do not expect to fully solve a problem of this scale on my own, Craft is open source and open to the community for development. I hope that as a community this can grow into a more advanced and widely adopted tool.
- alonsovm 6mo ago
  this project is something i'd do, i had the idea about the same time as you did, "why something like cargo for c++ doesn't exist?" and you did it, thanks I guess.
wild_pointer 6mo ago
What about cmkr? https://cmkr.build/ https://cmkr.build/
thegrim33 6mo ago
Project description is AI generated, even the HN post is AI generated, why should I spend any energy looking into your project when all you're doing is just slinging AI slop around and couldn't be bothered to put any effort in yourself?
forrestthewoods 6mo ago
Cmake is infamously not a build system. It is a build system generator. This is now a build system generator generator. This is the wrong solution imho. The right solution is to just build a build system that doesn’t suck. Cmake sucks. Generating suck is the wrong angle imho.
- nnevatie 6mo ago
  Cmake might suck, but is arguably the de-facto now. It's not standard, since the C++ committee does not want to deal with the real world (tooling).
  - forrestthewoods 6mo ago
    Python was also a shitshow and UV became the new standard in literally less than a year. That’s an existence proof that a new tool that doesn’t suck can take over an ecosystem.
    - nnevatie 6mo ago
      Completely agreed. However, typically a new tool needs to be significantly better for that to happen. In many ways, I see Meson already being that but it hasn't really gained traction at scale.
      - forrestthewoods 6mo ago
        also agreed. UV was so good it was just obviously significantly better. All I really want is Bazel/Buck but in a simple and easy to use way. I feel like this can be done.
littlestymaar 6mo ago
“Show HN” has really become a Claude code showcase in the last 6 months, maybe it's time to sunset the format at this point …
- bangaladore 6mo ago
  Yup, I read "— think Cargo, but for C/C++." and closed the tab.
  - nnevatie 6mo ago
    The em dash - it's always the em dash.
sebastos 6mo ago
The tough truth is that there already is a cargo for C/C++: Conan2. I know, python, ick. I know, conanfile.py, ick. But despite its warts, Conan fundamentally CAN handle every part of the general problem. Nobody else can. Profiles to manage host vs. target configuration? Check. Sufficiently detailed modeling of ABI to allow pre-compiled binary caching, local and remote? Check, check, check. Offline vs. Online work modes? Check. Building any relevant project via any relevant build system, including Meson, without changes to the project itself? Check. Support for pulling build-side requirements? Check. Version ranges? Check. Lockfiles? Check. Closed-source, binary-only dependencies? Check. Once you appreciate the vastness of the problem, you will see that having a vibrant ecosystem of different competing package managers sucks. This is a problem where ONE standard that can handle every situation is incalculably better than many different solutions which solve only slices of the problem. I don't care how terse craft's toml file is - if it can't cross compile, it's useless to me. So my project can never use your tool, which implies other projects will have the same problem, which implies you're not the one package manager / build system, which means you're part of the problem, not the solution. The Right Thing is to adopt one unilateral standard for all projects. If you're remotely interested in working on package managers, the best way to help the human race is to fix all of the outstanding things about Conan that prevent it from being the One Thing. It's the closest to being the One Thing, and yet there are still many hanging chads: - its terribly written documentation - its incomplete support for editable packages - its only nascent support for "workspaces" - its lack of NVIDIA recipes If you really can't stand to work on Conan (I wouldn't blame you), another effort that could help is the common package specification format (CPS). Making that a thing would also be a huge improvement. In fact, if it succeeds, then you'd be free to compete with conan's "frontend" ergonomics without having to compete with the ecosystem.
- looneysquash 6mo ago
  > The tough truth is that there already is a cargo for C/C++: Conan2 Is it though? When I read the tutorial: https://docs.conan.io/2/tutorial/consuming_packages/build_simple_cmake_project.html https://docs.conan.io/2/tutorial/consuming_packages/build_si... It says to hand write a `CMakeLists.txt` file. This is before it has me create a `conanfile.txt` even. I have the same complaint about vcpkg. It seems like it takes: `(conan | vcpkg) + (cmake | autotools) + (ninja | make)` to do the basics what cargo does.
singpolyma3 6mo ago
Next build a nice way to use normal Makefile with rust
linzhangrun 6mo ago
[flagged]
resonancel 6mo ago
Can't take this lib seriously when there're lots of gems like these in the codebase. // Open source directory dir_t* dir = open_dir(source_dir); // Find where dot is char* dot = strrchr(file, '.'); I thought ShowHN had banned LLM-generated contents, I can't be more wrong.
Panzerschrek 6mo ago
> You describe your project in a simple craft.toml I don't like it. Such format is generally restricted (is not Turing-complete), which doesn't allow doing something non-trivial, for example, choosing dependencies or compilation options based on some non-trivial conditions. That's why CMake is basically a programming language with variables, conditions, loops and even arithmetic.
- kakwa_ 6mo ago
  While I do get why CMake is a scripted build system, I cannot help but notice that other languages don't need it. In Rust, you have Cargo.toml, in go, it's a rather simple go.mod. And even in embedded C, you have platformio which manages to make due with a few .ini files. I would honestly love to see the cpp folks actually standardizing a proper build system and dependency manager. Today, just building a simple QT app is usually a daunting task, and other compiled ecosystems show us it doesn't have to be.
  - fisf 6mo ago
    Platformio is not simple by any means. That few .ini files generate a whole bunch of python, and this again relies on scons as build system. That's a nice experience as long as you stay within predefined, simple abstractions that somebody else provided. But it is very much a scripted build system, you just don't see it for trivial cases. For customizations, let alone a new platform, you will end up writing python scripts, and digging through the 200 pages documentation when things go wrong.
hulitu 6mo ago
Supply chain attack made easy.
chris_wot 6mo ago
Can it handle modules?
macgyverismo 6mo ago
I have to say, since CMakes FetchContent module has been available I have not had a need for a dependency manager outside of CMake itself. What exactly is it you do/need that can't be reasonably solved using the FetchContent module? https://cmake.org/cmake/help/latest/module/FetchContent.html https://cmake.org/cmake/help/latest/module/FetchContent.html
0xMalotru 6mo ago
Relevant XKCD: https://xkcd.com/927/ https://xkcd.com/927/
sourcegrift 6mo ago
Given how pathetic toml is with arrays, kinda sad people go with it.
ethanc8 6mo ago
KDE already has a meta-build tool for C++ called Craft, which handles dependency management and cross - compilation for CMake-built applications and libraries.
- ahartmetz 6mo ago
  AFAIK, Craft is only the most popular tool to build KDE software on (or perhaps for) Windows. On Linux, it's kdesrc-build (OG, Perl) or kde-builder (more recent, Python).
azizam 6mo ago
Great, no issue that a bit of LLM slop can't fix. Why even say "I built X"? I'd respect it more if you just said "Claude built X" or something.
Serhii-Set 6mo ago
[dead]
mixmastamyk 6mo ago
Would be great if there were a standard for these toml/ini project files across languages and tools.
swaminarayan 6mo ago
[dead]
c_chenfeng 6mo ago
[flagged]
- randerson_112 6mo ago
  Craft has a few commands to handle dependencies: craft add, craft update, craft remove. Craft add can take a path to a local Craft project and link it, or it can take a git url which will be cloned and linked automatically. Craft update updates a specific git dependency in your project to the newest version or updates all. Craft remove removes a dependency from your project.
wavint 6mo ago
[dead]
dfa11 6mo ago
this is really interesting +1 star PS is there a plan to include hermetic builds, from local sources / git submodules?

177 points by randerson_112 6mo ago

deleted 6mo ago

[deleted]

wg0 6mo ago

Yesterday I had to wrestle with CMake. But how this tool figures out where the header files and build instructions for the libraries are that are included? Any expected layout or industry wide consensus?

integricho 6mo ago
I believe it supports only projects having a working cmake setup, no extra magic
flohofwoe 6mo ago
I suspect it depends on a specific directory structure, e.g. look at this generated cmake file: https://github.com/randerson112/craft/blob/main/CMakeLists.txt https://github.com/randerson112/craft/blob/main/CMakeLists.t... ...and for custom requirements a manually created CMakeLists.extras.txt as escape hatch. Unclear to me how more interesting scenarios like compiler- and platform-specific build options (enable/disable warnings, defines, etc...), cross-compilation via cmake toolchain files (e.g. via Emscripten SDK, WASI SDK or Android SDK/NDK) would be handled. E.g. just trivial things like "when compiling for Emscripten, include these source files, but not those others".
eliemichel 6mo ago
CMakes piles up various generations of idioms so there are multiple ways of doing it, but personally I’ve learned to steer away from find_package() and other magical functions. Get all your dependencies as subdirectories (whichever way you prefer) and use add_subdirectory(). Use find_package() only in so-called "config" mode where you explicitly instruct cmake where to find the config for large precompiled dependencies only
- mathstuf 6mo ago
  FD: I am a CMake developer. Yes, config packages are better. But I think doing find_package everywhere is better. Assuming you install an SDK for others to use your project. If you're a "product", vendor away. The issue comes when you want to vendor X and Y and both vendor Z independently. Then you're stuck de-vendoring at least one and figuring out how to provide it yourself internally. IMO, better to just let Z make its own install tree and find it as a package from there. One can write good Find modules, but there is some "taste" involved. I wish we had more good examples to use as templates.

duped 6mo ago

FWIW: there is something fundamentally wrong with a meta-meta build system. I don't think you should bother generating or wrapping CMake, you should be replacing it.

SpaceNoodled 6mo ago
My thoughts exactly. I thought this was going to be some new thing, but it's just yet another reason that I'll stick with Makefiles.
- flohofwoe 6mo ago
  Do your Makefiles work across Linux, macOS and Windows (without WSL or MingW), GCC, Clang and MSVC, or allow loading the project into an IDE like Xcode or Visual Studio though? That's why meta-build-systems like cmake were created, not to be a better GNU Make.
  - uecker 6mo ago
    There is something fundamentally wrong with Windows or Visual Studio that it requires ugly solutions.
    - delta_p_delta_x 6mo ago
      Windows and Visual Studio solutions are perfectly fine. MSBuild is a declarative build syntax in XML, it's not very different from a makefile.
      - uecker 6mo ago
        XML is already terrible. But the main problem seems to be that they created something similar but incompatible to make.
    - flohofwoe 6mo ago
      Ok, then just cl.exe instead of gcc or clang. Completely different set of command line options from gcc and clang, but that's fine. C/C++ build tooling needs to be able to deal with different toolchains. The diversity of C/C++ toolchains is a strength, not a weakness :) One nice feature of MSVC is that you can describe the linker dependencies in the source files (via #pragma comment(lib, ...)), this enables building fairly complex single-file tools trivially without a build system like this: cl mytool.c ...without having to specify system dependencies like kernel32 etc... on the cmdline.

mc-serious 6mo ago

[flagged]

flohofwoe 6mo ago

Heh, looks like cmake-code-generators are all the rage these days ;) Here's my feeble attempt using Deno as base (it's extremely opinionated though and mostly for personal use in my hobby projects): https://github.com/floooh/fibs https://github.com/floooh/fibs One interesting chicken-egg-problem I couldn't solve is how to figure out the C/C++ toolchain that's going to be used without running cmake on a 'dummy project file' first. For some toolchain/IDE combos (most notably Xcode and VStudio) cmake's toolchain detection takes a lot of time unfortunately.

apparatur 6mo ago
I'm intrigued by the idea of writing one's own custom build system in the same language as the target app/game; it's probably not super portable or general but cool and easy to maintain for smaller projects: https://mastodon.gamedev.place/@pjako/115782569754684469 https://mastodon.gamedev.place/@pjako/115782569754684469

deleted 6mo ago

[deleted]

lgtx 6mo ago

The installation instructions being a `curl | sh` writing to the user's bashrc does not inspire confidence.

jjgreen 6mo ago
[flagged]
- Bjartr 6mo ago
  If you'd just left off "to fuck" you'd end up way less downvoted, if it even happened at all.
  - KPGv2 6mo ago
    [flagged]
    - jvanderbot 6mo ago
      Knowing the reason something is considered bad does not immediately change that fact that it is considered bad. Social / emotional signals still exist around that word.
  - jjgreen 6mo ago
    With fucks, without fucks, in iambic pentameter, anything vaguely critical of Rust will be downvoted. As you can see.
  - account42 6mo ago
    Probably not. This isn't prime time TV, some foul language is tolerated - but complaining about down-votes, especially preemptively, has a predictable response (IMO rightfully so).
    - jjgreen 6mo ago
      No complaints about down votes, simply warning the OP that (s)he will be getting some. Personally I quite like them, they indicate that I've irritated a Rust evangelist; that gives me a warm feeling inside.

spwa4 6mo ago

Just switch to bazel, copy my hermetic build config and just use it ... yes, you can hate me know.

cherryteastain 6mo ago

Seems to solve a problem very similar to Conan or vcpkg but without its own package archive or build scripts. In general, unlike Cargo/Rust, many C/C++ projects dynamically link libraries and often require complex Makefile/shell script etc magic to discover and optionally build their dependencies. How does craft handle these 'diamond' patterns where 2 dependencies may depend on versions of the same library as transitive dependencies (either for static or dynamic linking or as header-only includes) without custom build scripts like the Conan approach?

Surac 6mo ago

Uses CMAKE, Sorry not for me. Call me old but i prefere good old make or batch. Maybe it's because i can understand those tools. Debugging CMAKE build problems made me hate it. Also i code for embedded CPU and most of the time CMAKE is just overkill and does not play well the compiler/binutils provided. The Platform independency is just not happening in those environments.

bluGill 6mo ago
For simple projects. Make is easier for simple things I will grant. However when your projects gets complex at all make becomes a real pain and cmake becomes much easier. Cmake has a lot of warts, but they have also put a lot of effort into finding and fixing all those weird special cases. If your project uses CMake odds are high it will build anywhere.
- tosti 6mo ago
  Odds are high the distro maintainer will lose hair trying to package it
- lkjdsklf 6mo ago
  Also, for better or worse, cmake is pretty much the "standard" for C/C++ these days. Fighting the standard often creates it's own set of problems and nightmares that just aren't worth it. Especially true in C++ where yhou often have to integrate with other projects and their build systems. Way easier if you just use cmake like everyone else. Even the old hold outs, boost and google open source, now use cmake for their open source stuff.
delta_p_delta_x 6mo ago
> most of the time CMAKE is just overkill and does not play well the compiler/binutils provided You need to define a CMake toolchain[1] and pass it to CMake with --toolchain /path/to/file in the command-line, or in a preset file with the key `toolchainFile` in a CMake preset. I've compiled for QNX and ARM32 boards with CMake, no issues, but this needs to be done. [1]: https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html https://cmake.org/cmake/help/latest/manual/cmake-toolchains....

looneysquash 6mo ago

Nice. I have been thinking of making something similar. Now hopefully I don't have to! Not sure how big your plans are. My thoughts would be to start as a cmake generator but to eventually replace it. Maybe optionally. And to integrate suppoet for existing package managers like vcpkg. At the same time, I'd want to remain modular enough that's it's not all or nothing. I also don't like locking. But right now package management and build system are decoupled completely. And they are not like that in other ecosystems. For example, Cmake can use vcpkg to install a package but then I still have to write more cmake to actually find and use it.

psyclobe 6mo ago
> For example, Cmake can use vcpkg to install a package but then I still have to write more cmake to actually find and use it. I have this solved at our company. We have a tool built on top of vcpkg, to manage internal + external dependencies. Our cmake linker logic leverages the port names and so all you really do is declare your manifest file (vcpkg.json) then declare which one of them you will export publicly. Everything after that is automatic including the exported cmake config for your library.

tombert 6mo ago

This certainly seems less awful than the typical C building process. What I've been doing to manage dependencies in a way that doesn't depress me much has been Nix flakes, which allows me a pretty straightforward `nix build` with the correct dependencies built in. I'm just a bit curious though; a lot of C libraries are system-wide, and usually require the system package manager (e.g. libsdl2-dev) does this have an elegant way to handle those?

randerson_112 6mo ago
Yes, many libraries are system wide that is true. This is something I had on the list of features to add. System dependencies. Thank you for the feedback!

mococa 6mo ago

Compared to Conan, what are the advantages?

randerson_112 6mo ago
Craft has project management and generates starter project structure. You can generate header and source files with boilerplate starter code. Craft manages the building of the project so you don’t need to write much CMake. You can also save project structures as templates and instantiate those templates in new projects ready to go.
- mococa 6mo ago
  How you can be better than CMake?

bluGill 6mo ago

Anyone can make a tool that solves a tiny part of the problem. however the reason no such tool has caught on is because of all the weird special cases you need to handle before it can be useful. Even if you limit your support to desktop: OS/X and Windows that problem will be hard, adding various linux flavors is even more difficult, not to mention BSD. The above is the common/mainstream choices, there Haiku is going to be very different, and I've seen dozens of others over the years, some of them have a following in their niche. Then there are people building for embedded - QNX, vxworks, or even no OS just bare metal - each adding weirdness (and implying cross compiling which makes everything harder because your assumptions are always wrong). I'm sorry I have to be a downer, but the fact is if you can use the word "I" your package manager is obviously not powerful enough for the real world.

the__alchemist 6mo ago
I will categorize this as a pattern I've seen which leads to stagnation, or is at least aiming for it. Usually these are built on one or more assumption which doesn't hold. The flow of this pattern: - Problem exists - Proposals of solutions, (varying quality), or not - "You can't just solve this. It's complicated! This problem must exist". (The post I'm replying to - Problem gets solved, hopefully. Anecdotes I'm choosing based on proximity to this particular problem: uv and cargo. uv because people said the same thing about python packaging, and cargo because its adjacent to C and C++ in terms of being a low-level compiled language used for systems programming, embedded/bare-metal etc. The world is rich in complexity, subtlety, and exceptions to categorization. I don't think this should block us from solving problems.
- bluGill 6mo ago
  I didn't say the problem couldn't be solved. I said the problem can't be solved by one person. There is a difference. (maybe it can be solved by one person over a few decades)
  - tekne 6mo ago
    I mean -- if I'm going to join a team to solve the hard 20%, I'd like to see the idea validated against the easy 80% first. If it's really bad, at least the easy 20%.

seniorThrowaway 6mo ago

Having to work around a massive C++ software project daily, I wish you luck. We use conan2, and while it can be very challenging to use, I've yet to find something better that can handle incorporating as dependencies ancient projects that still use autoconf or even custom build tooling. It's also very good at detecting and enforcing ABI compatibility, although there are still some gaps. This problem space is incredibly hard and improving it is a prime driver for the creation of many of the languages that came after C/C++

mgaunard 6mo ago
I find that conan2 is mostly painful with ABI. Binaries from GCC are all backwards compatible, as are C++ standard versions. The exception is the C++11 ABI break. And yet it will insist on only giving you binaries that match exactly. Thankfully there are experimental extensions that allow it to automatically fall back.

gavinray 6mo ago

The least painful C/C++ build tool I've used is xmake https://github.com/xmake-io/xmake https://github.com/xmake-io/xmake The reason why I like it (beyond ease-of-use) is that it can spit out CMakeLists.txt and compile_commands.json for IDE/LSP integration and also supports installing Conan/vcpkg libraries or even Git repos. set_project("myapp") set_languages("c++20") add_requires("conan::fmt/11.0.2", {alias = "fmt"}) add_requires("vcpkg::fmt", {alias = "fmt"}) add_requires("git://github.com/fmtlib/fmt v11.0.2", {alias = "fmt"}) target("myapp") set_kind("binary") add_files("src/*.cpp") add_packages("fmt") Then you use it like # Generate compile_commands.json and CMakeLists.txt $ xmake project -k compile_commands $ xmake project -k cmake # Build + run $ xmake && xmake run myapp

delta_p_delta_x 6mo ago
Agreed, xmake seems very well-thought-out, and supports the most modern use-cases (C++20 named modules, header unit modules, and `import std`, which CMake still has a lot of ceremony around). I should switch to it.
ethin 6mo ago
I would happily switch to it in a heartbeat if it was a lot more well-documented and if it supported even half of what CMake does. As an example of what I mean, say I want to link to the FMOD library (or any library I legally can't redistribute as an SDK). Or I want to enable automatic detection on Windows where I know the library/SDK is an installer package. My solution, in CMake, is to just ask the registry. In XMake I still can't figure out how to pull this off. I know that's pretty niche, but still. The documentation gap is the biggest hurtle. A lot of the functions/ways of doing things are poorly documented, if they are at all. Including a CMake library that isn't in any of the package managers for example. It also has some weird quirks: automatic/magic scoping (which is NOT a bonus) along with a hack "import" function instead of using native require. All of this said, it does work well when it does work. Especially with modules.
IshKebab 6mo ago
I've had some experience with this but it seems to be rather slow, very niche and tbh I can't see a reason to use it over CMake.

shevy-java 6mo ago

Will take C only 51 years to adopt.

dima55 6mo ago

If you think cmake isn't very good, the solution isn't to add more layers of crap around cmake, but to replace it. Cmake itself exists because a lot of humans haven't bothered to read the gnu make manual, and added more cruft to manage this. Please don't add to this problem. It's a disease

dymk 6mo ago
As much of a dog as cmake is, "just use make!" does not solve many of the problems that cmake makes a go at. It's like saying go write assembler instead of C because C has so many footguns.
- dima55 6mo ago
  GNU Make has a debugger. This alone makes it far superior to every other build tool I've ever seen. The cmake debugging experience is "run a google search, and try random stuff recommended by other people that also have no idea how the thing works". This shouldn't be acceptable.
  - beckford 6mo ago
    That hasn't been true for a few years at least. https://www.jetbrains.com/help/clion/cmake-debug.html https://www.jetbrains.com/help/clion/cmake-debug.html is has had CMake debugging since cmake 3.27. Ditto for vscode and probably other C IDEs I am not familiar with. So does Gradle for Java. GNU make is hardly exclusive.
wiseowise 6mo ago
I'm all for shitting on CMake, but Jesus, to suggest Make as a replacement/improvement is an unhinged take.
- dima55 6mo ago
  I'm suggesting that people creating build systems read the make manual. Surely this isn't controversial?

mutkach 6mo ago

Please consider adding `cargo watch` - that would be a killer feature!

randerson_112 6mo ago
Yes! This is definitely on the list of features to add. Thank you for the feedback!

looneysquash 6mo ago

Besides Cargo, you might want to take a look at Python's pyproject.toml standard. https://packaging.python.org/en/latest/guides/writing-pyproject-toml/ https://packaging.python.org/en/latest/guides/writing-pyproj... It's similar, but designed for an existing ecosystem. Cargo is designed for `cargo`, obviously. But `pyproject.toml` is designed for the existing tools to all eventually adopt. (As well as new tools, of course.)

kjksf 6mo ago

In the age of AI tools like this are pointless. Especially new ones, given existence of make, cmake, premake and a bunch of others. C++ build system, at the core, boils down to calling gcc foo.c -o foo.obj / link foo.obj foo.exe (please forgive if I got they syntax wrong). Sure, you have more .c files, and you pass some flags but that's the core. I've recently started a new C++ program from scratch. What build system did I write? I didn't. I told Claude: "Write a bun typescript script build.ts that compiles the .cpp files with cl and creates foo.exe. Create release and debug builds, trigger release build with -release cmd-line flag". And it did it in minutes and it worked. And I can expand it with similar instructions. I can ask for release build with all the sanitize flags and claude will add it. The particulars don't matter. I could have asked for a makefile, or cmake file or ninja or a script written in python or in ruby or in Go or in rust. I just like using bun for scripting. The point is that in the past I tried to learn cmake and good lord, it's days spent learning something that I'll spent 1 hr using. It just doesn't make sense to learn any of those tools given that claude can give me working any build system in minutes. It makes even less sense to create new build tools. Even if you create the most amazing tool, I would still choose spending a minute asking claude than spending days learning arbitrary syntax of a new tool.

duped 6mo ago
You're missing finding library/include paths, build configuration (`-D` flags for conditional compilation), fetching these from remote repositories, and versioning.
- jcotton42 6mo ago
  Also other tasks like compiling resource or translation files.
deleted 6mo ago
[deleted]
randerson_112 6mo ago
This is a fair and valid point. However, why leave your workflow to write a prompt to an AI when you can run simple commands in your workspace. Also you are most likely paying to use the AI while Craft is free and open source and will only continue to improve. I respect your feedback though, thank you!

adev_ 6mo ago

Feedback of someone who is used to manage large (>1500) software stack in C / C++ / Fortran / Python / Rust / etc: - (1) Provide a way to compile without internet access and specify the associated dependencies path manually. This is absolutely critical. Most 'serious' multi-language package managers and integration systems are building in a sandbox without internet access for security reasons and reproducibility reasons. If your build system does not allow to build offline and with manually specified dependencies, you will make life of integrators and package managers miserable and they will avoid your project. (2) Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity. People expect code to be portable and shippable. Good default options should be CMake equivalent of "RelWithDebInfo" (meaning: -O2 -g -DNDEBUG ). -O3 can be argued. -march=native is always always a mistake. - (3) Allow your build tool to be built by an other build tool (e.g CMake). Anybody caring about reproducibility will want to start from sources, not from a pre-compiled binary. This also matter for cross compilation. - (4) Please offer a compatibility with pkg-config (https://en.wikipedia.org/wiki/Pkg-config https://en.wikipedia.org/wiki/Pkg-config) and if possible CPS (https://cps-org.github.io/cps/overview.html https://cps-org.github.io/cps/overview.html) for both consumption and generation. They are what will allow interoperability between your system and other build systems. - (5) last but not least: Consider seriously the cross-compilation use case. It is common in the world of embedded systems to cross compile. Any build system that does not support cross-compilation will be de facto banned from the embedded domain.

moralestapia 6mo ago
>15000 15000 what?
- adev_ 6mo ago
  1500 C/C++ individual software components. The 15000 was a typo on my side. Fixed.
  - moralestapia 6mo ago
    I see, thanks. I didn't mind the number it just wasn't clear what was it about.

nesarkvechnep 6mo ago

As long as it's for C/C++ and not C or C++, I'm skeptical.

randerson_112 6mo ago
Why do you say this? I respect it, I'm just curious.
- avadodin 6mo ago
  C/C++ is HR-newspeak out of the 1990s(at the time it was not clear that anyone would still want to use C and MSVC did move their compiler to C++). It signals that the speaker doesn't understand that the two are different languages with very different communities. I don't really think that C users are entirely immune to dependency hell, if that's what OP meant, though. It is orthogonal. As a user, I do believe it sucks when you depend on something that is not included by default on all target platforms(and you fail to include it and maintain it within your source tree*).
  - unclad5968 6mo ago
    What part of the build process is different for C?
    - avadodin 6mo ago
      I explained why C/C++ rubbed op the wrong way. It has nothing to do with a build process. It is probably true that more average C programs can be built with plain Makefiles or even without a Makefile than C++, though. You can of course add dependencies on configure scripts, m4, cmake, go, python or rust when building a plain self-contained C program and indeed many do.
      - unclad5968 6mo ago
        Well the post is about build tools, so I assumed we were talking about that.

einpoklum 6mo ago

Impression before actually trying this: CMake is a combination of a warthog of a specification language, and mechanisms for handling a zillion idiosyncracies and corners cases of everything. I doubt than < 10,000 lines of C code can cover much of that. I am also doubtful that developers are able to express the exact relations and semantic nuances they want to, as opposed to some default that may make sense for many projects, but not all. Still - if it helps people get started on simpler or more straightforward projects - that's neat :-)

randerson_112 6mo ago

Thank you everyone for the feedback so far! I just wanted to say that I understand this is not a fully cohesive and functional project for every edge case. This is the first day of releasing it to the public and it is only the beginning of the journey. I do not expect to fully solve a problem of this scale on my own, Craft is open source and open to the community for development. I hope that as a community this can grow into a more advanced and widely adopted tool.

alonsovm 6mo ago
this project is something i'd do, i had the idea about the same time as you did, "why something like cargo for c++ doesn't exist?" and you did it, thanks I guess.

wild_pointer 6mo ago

What about cmkr? https://cmkr.build/ https://cmkr.build/

thegrim33 6mo ago

Project description is AI generated, even the HN post is AI generated, why should I spend any energy looking into your project when all you're doing is just slinging AI slop around and couldn't be bothered to put any effort in yourself?

forrestthewoods 6mo ago

Cmake is infamously not a build system. It is a build system generator. This is now a build system generator generator. This is the wrong solution imho. The right solution is to just build a build system that doesn’t suck. Cmake sucks. Generating suck is the wrong angle imho.

nnevatie 6mo ago
Cmake might suck, but is arguably the de-facto now. It's not standard, since the C++ committee does not want to deal with the real world (tooling).
- forrestthewoods 6mo ago
  Python was also a shitshow and UV became the new standard in literally less than a year. That’s an existence proof that a new tool that doesn’t suck can take over an ecosystem.
  - nnevatie 6mo ago
    Completely agreed. However, typically a new tool needs to be significantly better for that to happen. In many ways, I see Meson already being that but it hasn't really gained traction at scale.
    - forrestthewoods 6mo ago
      also agreed. UV was so good it was just obviously significantly better. All I really want is Bazel/Buck but in a simple and easy to use way. I feel like this can be done.

littlestymaar 6mo ago

“Show HN” has really become a Claude code showcase in the last 6 months, maybe it's time to sunset the format at this point …

bangaladore 6mo ago
Yup, I read "— think Cargo, but for C/C++." and closed the tab.
- nnevatie 6mo ago
  The em dash - it's always the em dash.

sebastos 6mo ago

The tough truth is that there already is a cargo for C/C++: Conan2. I know, python, ick. I know, conanfile.py, ick. But despite its warts, Conan fundamentally CAN handle every part of the general problem. Nobody else can. Profiles to manage host vs. target configuration? Check. Sufficiently detailed modeling of ABI to allow pre-compiled binary caching, local and remote? Check, check, check. Offline vs. Online work modes? Check. Building any relevant project via any relevant build system, including Meson, without changes to the project itself? Check. Support for pulling build-side requirements? Check. Version ranges? Check. Lockfiles? Check. Closed-source, binary-only dependencies? Check. Once you appreciate the vastness of the problem, you will see that having a vibrant ecosystem of different competing package managers sucks. This is a problem where ONE standard that can handle every situation is incalculably better than many different solutions which solve only slices of the problem. I don't care how terse craft's toml file is - if it can't cross compile, it's useless to me. So my project can never use your tool, which implies other projects will have the same problem, which implies you're not the one package manager / build system, which means you're part of the problem, not the solution. The Right Thing is to adopt one unilateral standard for all projects. If you're remotely interested in working on package managers, the best way to help the human race is to fix all of the outstanding things about Conan that prevent it from being the One Thing. It's the closest to being the One Thing, and yet there are still many hanging chads: - its terribly written documentation - its incomplete support for editable packages - its only nascent support for "workspaces" - its lack of NVIDIA recipes If you really can't stand to work on Conan (I wouldn't blame you), another effort that could help is the common package specification format (CPS). Making that a thing would also be a huge improvement. In fact, if it succeeds, then you'd be free to compete with conan's "frontend" ergonomics without having to compete with the ecosystem.

looneysquash 6mo ago
> The tough truth is that there already is a cargo for C/C++: Conan2 Is it though? When I read the tutorial: https://docs.conan.io/2/tutorial/consuming_packages/build_simple_cmake_project.html https://docs.conan.io/2/tutorial/consuming_packages/build_si... It says to hand write a `CMakeLists.txt` file. This is before it has me create a `conanfile.txt` even. I have the same complaint about vcpkg. It seems like it takes: `(conan | vcpkg) + (cmake | autotools) + (ninja | make)` to do the basics what cargo does.

singpolyma3 6mo ago

Next build a nice way to use normal Makefile with rust

linzhangrun 6mo ago

[flagged]

resonancel 6mo ago

Can't take this lib seriously when there're lots of gems like these in the codebase. // Open source directory dir_t* dir = open_dir(source_dir); // Find where dot is char* dot = strrchr(file, '.'); I thought ShowHN had banned LLM-generated contents, I can't be more wrong.

Panzerschrek 6mo ago

> You describe your project in a simple craft.toml I don't like it. Such format is generally restricted (is not Turing-complete), which doesn't allow doing something non-trivial, for example, choosing dependencies or compilation options based on some non-trivial conditions. That's why CMake is basically a programming language with variables, conditions, loops and even arithmetic.

kakwa_ 6mo ago
While I do get why CMake is a scripted build system, I cannot help but notice that other languages don't need it. In Rust, you have Cargo.toml, in go, it's a rather simple go.mod. And even in embedded C, you have platformio which manages to make due with a few .ini files. I would honestly love to see the cpp folks actually standardizing a proper build system and dependency manager. Today, just building a simple QT app is usually a daunting task, and other compiled ecosystems show us it doesn't have to be.
- fisf 6mo ago
  Platformio is not simple by any means. That few .ini files generate a whole bunch of python, and this again relies on scons as build system. That's a nice experience as long as you stay within predefined, simple abstractions that somebody else provided. But it is very much a scripted build system, you just don't see it for trivial cases. For customizations, let alone a new platform, you will end up writing python scripts, and digging through the 200 pages documentation when things go wrong.

hulitu 6mo ago

Supply chain attack made easy.

chris_wot 6mo ago

Can it handle modules?

macgyverismo 6mo ago

I have to say, since CMakes FetchContent module has been available I have not had a need for a dependency manager outside of CMake itself. What exactly is it you do/need that can't be reasonably solved using the FetchContent module? https://cmake.org/cmake/help/latest/module/FetchContent.html https://cmake.org/cmake/help/latest/module/FetchContent.html

0xMalotru 6mo ago

Relevant XKCD: https://xkcd.com/927/ https://xkcd.com/927/

sourcegrift 6mo ago

Given how pathetic toml is with arrays, kinda sad people go with it.

ethanc8 6mo ago

KDE already has a meta-build tool for C++ called Craft, which handles dependency management and cross - compilation for CMake-built applications and libraries.

ahartmetz 6mo ago
AFAIK, Craft is only the most popular tool to build KDE software on (or perhaps for) Windows. On Linux, it's kdesrc-build (OG, Perl) or kde-builder (more recent, Python).

azizam 6mo ago

Great, no issue that a bit of LLM slop can't fix. Why even say "I built X"? I'd respect it more if you just said "Claude built X" or something.

Serhii-Set 6mo ago

[dead]

mixmastamyk 6mo ago

Would be great if there were a standard for these toml/ini project files across languages and tools.

swaminarayan 6mo ago

[dead]

c_chenfeng 6mo ago

[flagged]

randerson_112 6mo ago
Craft has a few commands to handle dependencies: craft add, craft update, craft remove. Craft add can take a path to a local Craft project and link it, or it can take a git url which will be cloned and linked automatically. Craft update updates a specific git dependency in your project to the newest version or updates all. Craft remove removes a dependency from your project.

wavint 6mo ago

[dead]

dfa11 6mo ago

this is really interesting +1 star PS is there a plan to include hermetic builds, from local sources / git submodules?