Live data from Hacker News

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

github.com

71–80 of 181 posts

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

#71
post #69
post #49

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 reas…

> -march=native is always always a mistake Gentoo user : hold my beer.

It's also an option on NixOS but I haven't managed to get it working unlike Gentoo.

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

#72
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 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 :-)

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

#73
post #69
post #49

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 reas…

> -march=native is always always a mistake Gentoo user : hold my beer.

Gentoo binaries aren't shipped that way

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

#74
post #62

Earlier quoted context omitted.

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 choo…

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)

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%.

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

#76

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 incredib…

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.

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

#77
post #23

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 el…

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!

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

#78
post #62

Earlier quoted context omitted.

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 choo…

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)

This is true. There is no way I could solve a problem of this scale by myself. That is why this is an open source project and open to everyone to make changes on. There is still much more to improve, this is only day 1 of release to the public.

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

#79
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.
Post reply on HN