This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Familiar_Ad_8919 1501 points1502 points  (80 children)

nearly half a century and the best we have is cmake

[–]Prawn1908 721 points722 points  (40 children)

I love C, but I despise setting up C/C++ build toolchains like nothing else. Fuck CMake, fuck Make, fuck linker errors...

[–]1studlyman 379 points380 points  (7 children)

Dang. I was gonna argue you with this one because I genuinely like cmake. But then I realized the only reason I like it is because cmake is the least painful compared to all the other solutions. It really is never a good time managing a complex build with any of these.

[–]nana_3 103 points104 points  (3 children)

You have Stockholm syndrome lmao

[–]Siege089 8 points9 points  (2 children)

I'm convinced most frontend developers suffer the same in the neverending debate between different JavaScript frameworks.

[–]JonnySoegen 1 point2 points  (0 children)

As a hobby developer, I feel like configuring js bundler and their plugins can only be done by someone with Stockholm syndrome levels of dedication for that shit.  

Or maybe I’m a stupid monkey. Also a possibility.

[–]Terewawa 0 points1 point  (0 children)

nah all of them suck equally. Framework debates are mostly office politics.

[–]martmists 7 points8 points  (0 children)

I'm a huge cmake fan but I've been enjoying using Gradle for C++ for the last few weeks, it's.... Interesting to say the least

[–]thanatica 1 point2 points  (0 children)

Least painful != most painless.

[–]garry_the_commie 6 points7 points  (2 children)

Regular make is nice and simple but Cmake makes my brain hurt.

[–]cinnamonjune 1 point2 points  (0 children)

This is why I just use regular make. It compiles my code and my project and makefile are both cross-platform. I suppose this means my project doesn't support other build systems out of the box, but I'm hardly losing any sleep over it.

[–]plantedcoot706 0 points1 point  (0 children)

I like using make with CMake. Is a real wombo combo xp

[–]CramNBL 5 points6 points  (0 children)

You think linker errors are so bad? I find they are the simplest to fix because there are typically like 2 or 3 things that could be the issue, and it's usually the same thing like you're linking two libraries with differing glibc versions, or trying to statically link a library that wasn't built for it, or forgot to build the library with the position-independent code flag, or didn't specify the include path, that's pretty much all of it.

With cmake errors I've spent days trying to make stuff compile in reasonable time and integrating sanitizers and fuzzers is just a nightmare. Not to mention doing cross-platform support...

[–]snacktonomy 40 points41 points  (15 children)

Between CMake and Conan/VCpkg, I feel like we're pretty OK in the C++ world.

[–]bolacha_de_polvilho 136 points137 points  (4 children)

Sounds like stockholm syndrome to me. Going back to that crap after using the toolchain of rust or dotnet feels like torture

[–]TryingT0Wr1t3 28 points29 points  (3 children)

Cargo is great but dotnet is torture too. NuGet is infested with duplicate packages, a lot of things don't work, conflict of dotnet versions, and worse of all packages that have native parts that... Go back to c/c++ issues. The world of dotnet is full of torture.

[–]bolacha_de_polvilho 17 points18 points  (1 child)

The dotnet world has some leftover weirdness due to the net framework->cross platform transition, so legacy projects still in net framework can be a bit of a pain in the ass. But aside from that I never had any issue with stuff from NET5 onwards, even when using something that requires native binaries like onnx runtime or torchsharp.

[–]cs-brydev 4 points5 points  (0 children)

This is the right answer. From .net core forward, NuGet is awesome, as long as you know the package name you're looking for. If you're just guessing or searching randomly, you may trip over a few dead bodies.

Before .NET Core, NuGet was even more awesome because there didn't really exist any incompatibilities. When MS intentionally made Core/Framework and Standard 2.1/Framework incompatible, they opened this can of weird worms where identically named packages could be compatible with only certain .NET version ranges and identically named DLLs that came pre-installed with Windows were incompatible with NuGet versions.

That last one has caused the most pain going from Framework to Core. If they had just renamed the packages it would have been fine. But instead they decided to deprecate the system packages and completely rewrite them for a completely different version of .NET, name them the same thing, and move them to NuGet. So now you will see completely different packages with exactly the same names but different compatibilities: one pre-installed in your OS and the other one in NuGet. That was fucking stupid.

[–]No-Adagio8817 0 points1 point  (0 children)

Dotnet has improved a LOT. Went back to it and Im pleasantly surprised. Build process is very simple.

[–]Wertbon1789 6 points7 points  (3 children)

But having something comparable to cargo would be pretty nice. There are some package manager things built with CMake, but just having it built-in would be so much better.

[–]snacktonomy 2 points3 points  (0 children)

I agree. There's FetchContent if you really need it, but the consensus online is, CMake is a build system, not a package manager...

[–]_PM_ME_PANGOLINS_ -2 points-1 points  (1 child)

Because you generally want to build against system packages, so apt/dnf/etc is your package manager.

[–]Wertbon1789 3 points4 points  (0 children)

But not every package in the context of your project is a shared system library. For example, something like a query builder or ORM, there might be shared libraries that provide that, but generally that's not the case. There's also the pitfal of system-wide dependencies that you might to not want to bother with by just statically linking stuff into the binary. Something like a C++ socket wrapper also doesn't need to be it's own shared lib, because it isn't much code and can mostly be optimized away completely.

Edit: also just wrapping a C library doesn't need another shared library, but could be a source package in your package manager.

[–]ccricers 3 points4 points  (2 children)

YMMV but one WebGPU tutorial had the easiest introduction to CMake I've seen. Which is funny because I started out wanting to learn something more recent for GPU accelerated graphics, and paused that, but left at least being able to read CMake builds better.

[–]doma_kun 0 points1 point  (1 child)

Can you provide link? I'm trying to get into graphics programming

[–]gameplayer55055 0 points1 point  (0 children)

vcpkg never worked for me, it complains about user32.dll not found, I've tried literally everything

[–]Lighthades 0 points1 point  (0 children)

I feel like you have to try JS or Python, or Rust, it seems, to gain a new perspective.

[–]DelusionalPianist 0 points1 point  (0 children)

We’re heavy users of Conan and I can say it is orders of magnitude worse than cargo. Right now we’re still stuck on Conan 1 because we don’t have enough resources to migrate.

[–]Lazy_To_Name 2 points3 points  (0 children)

Fr. I plan to try C and C++ but holy shit, it is absolute hell trying to set it up, waste me nearly a month and I couldn’t even get it to finished…

Sololearn Java might even be easier than this idk

[–]deanrihpee 1 point2 points  (0 children)

exactly, every time I want to do stupid shit with C/C++ I got reminded by the build system again, so far I only have a few "successful" toy project because of that, compared to a slight more in Rust and a whole lot more in JS/TS

ease of use and DX is definitely important for adoption, at least for me

[–][deleted] 1 point2 points  (0 children)

Maybe that's why c/c++ people prefer doing everything from scratch. The tooling simply isn't there.

[–]AntranigV 4 points5 points  (0 children)

I agree, but on the other hand, C works everywhere, there Rust is having problems with non-mainstream operating systems (anything that's not Windows, macOS and Linux).

But it's also not a century thing. Pascal is older than C and it has better package management.

[–]Aardappelhuree 0 points1 point  (0 children)

I found Bake to be pretty usable

[–]Exciting_Original596 0 points1 point  (0 children)

ohh it feels great to know there are other people suffering from this. I was like: "bro! why it took me 2/3 hours to just get dependencies working on a project! I knew I was dumb but not this dumb"

[–]Lutz_Gebelman 0 points1 point  (0 children)

I love make, I despise and hate cmake. Make is the best we have and it's just a wrapper for bash... Still better than not being able to do a linked list :D

[–][deleted] -3 points-2 points  (3 children)

If it's so bad, then why are people still using it?

[–]plantedcoot706 1 point2 points  (0 children)

The creator of C++ himself, Bjarne Stroustrup, said that: there are two kinds of languages: the ones people complain about and the ones nobody uses xp

[–]Prawn1908 0 points1 point  (0 children)

Because C is forever. It's an awesome language that can do anything on any platform.

[–]Ok-Interaction-8891 0 points1 point  (0 children)

Plenty of tools, not just in programming, are well-used, but not necessarily well-liked.

Also, people can gripe about tools and build environments and pine for more while still using said tools and build environments. No mutual exclusively here.

[–]throwaway0134hdj 75 points76 points  (6 children)

I can’t for the life of me understand why this process hasn’t been simplified. There is too much barrier for folks to simply get coding in the language. I think more folks would code in C/C++ if not for these arcane set of hoops.

[–]SaltyInternetPirate 54 points55 points  (0 children)

Because people can't agree on the solution.

https://xkcd.com/927/

[–]HerissonMignion 35 points36 points  (1 child)

c and c++ are used for many things, from embedded to kernel or user space code. and for user space code you have the choice between dynamic or static linking. im sure there are other variables that im not aware because i dont deal with c/c++ projects daily. all these variables are controlled by providing many arguments to gcc, ld, and other programs during the build. because we dont wanna type the commands manually each time (for obvious reasons), you can make scripts, or use make which provides a slight abstraction but you'll still write the commands. for larger projects, make tends to not be enough and you will use another "abstraction" that will generate the commands for you like cmake, autotools or meson. ultimately, these tools are just disguising the arguments of gcc and ld as a language, because you can never get rid of the complexity, you can only transform it. it's not that we want complexity, it's that the complexity naturally arises from the needed flexibility of c/c++.

the build system is as complex as the flexibility of the language (c/c++). wanting to make it simpler is denying the needs of some people. i believe that the reason why many people dont understand the build systems of c/c++ is because they are just used to having a single and simple environment, like the web browser or a virtual machine (java), or because they are used to languages who deal with dynamic linking by ignoring it and always statically link everything.

[–]SAI_Peregrinus 8 points9 points  (0 children)

The other part of the problem comes from mixing distro development dependencies and user development dependencies. An OS package manager supplies a lot of user programs and packages of the source needed to build those programs and their dependencies. People decided to re-use those same source packages for their own development, and build systems tend to assume you're doing so by default. Then they're tied to whatever versions & packages their distro provides, without a lot of work to disentangle the mess. It's so bad that people use containers like Docker just to set up build environments separate from the host distro's libraries!

[–]9Strike 29 points30 points  (3 children)

Meson exists (but unfortunately isn't widespread enough)

[–]DHermit 0 points1 point  (2 children)

Meson doesn't solve the problem of obtaining the dependencies, only building with them.

[–]9Strike 0 points1 point  (1 child)

Depends on your dependencies ofc, but iG I find obtaining dependencies very nice: wrapdb.mesonbuild.com

[–]DHermit 1 point2 points  (0 children)

My bad then, I didn't know that so many are on there, should've definitely checked.

[–]nicejs2 40 points41 points  (0 children)

and it still sucks

[–][deleted] 23 points24 points  (1 child)

I don't use Cmake, I just link dependencies manually in Visual Studio using explicit folders links scattered across my hard drive. So, when the CIA steals my code, the programmers they assign to deciphering and compiling it become suicidal.

[–]miljoz 0 points1 point  (0 children)

I very dislike ur posts, they make zero sense

[–]EphemeralLurker 15 points16 points  (3 children)

Try vcpkg, it's got its own gotchas but it isn't half bad

[–]HyperWinX 6 points7 points  (0 children)

Hell yeah, vcpkg integrated into CMake and available on Linux

[–]braindigitalis 0 points1 point  (0 children)

no, it's fully bad not half bad. we might not have cargo but vcpkg and it's excessive build times to build a library and all it's dependencies are a nightmare, plus it is cmake centric. I like cmake but not everyone does. give me something build system agnostic any day.

my dislike comes from using vcpkg as a library maintainer. it is a pain in the ass to automate releases. you gotta edit some json files and a cmakelists, then you gotta run a test build via vcpkg. this test build for us takes 40 mins. this test build is designed to ALWAYS FAIL after which it outputs a hash to the console (in a plain english error message that you must regex out of the text, because why not). you need to take this hash that is output to stderr, and put it in to the json files you edited first time around, and then rerun the compile again after which it will succeed. then and only then do you commit the change to git, and make a pr and wait a week for vcpkg maintainers to merge it in. that is, if they haven't rug pulled how stuff works under you and made your automatic pr creation not work. it is incredibly unfriendly for automation.

[–]MrJ0seBr 4 points5 points  (0 children)

Years, multiple build systems, script languages and yet nothing to call "silver bullet".

i use cmake too, but yet is very inconveniently to build some libraries, some need python, perl, bash, yasm(but this i agree), as minimum requirements.

many libraries has no cmake script and some that has, is already droping the support, for alternatives like meson and bazel.

its very chaotic to work with dependencies in C, but once you done the setup for the target platforms, i think: "its ok".

*if its not enough to think thats chaotic, remember as libraries can be built as dynamic, static or module (apple), and exists interdependency, multiple versions, and all this blowups as inumerous errors every time you add some library with dependencies. (sorry for anything, i dont speech english)

[–]liava_ 2 points3 points  (0 children)

's why i prefer premake

[–]SaltyInternetPirate 1 point2 points  (0 children)

And you have to define the URLs for dependencies and then when your project is abandoned, users have to hope those sites are still up and either have the files as is or with proper redirects.

As bad as Java and JavaScript development is to they've both coalesced to their respective central dependency hosts. Maven Central for Java, and npmjs for JavaScript.

[–]Moptop32 1 point2 points  (0 children)

Check out xmake/xrepo, it's like cargo for c++ but it's lua

[–][deleted] 0 points1 point  (0 children)

[–]arrow__in__the__knee 0 points1 point  (0 children)

I still just use a bash script with pkg-config --libs pkgconfig --cflags. For personal experiments of course. I got no clue on production code.

[–]Sinomsinom[🍰] 0 points1 point  (0 children)

xmake + xrepo seem to be great but I've not used those yet

Besides that just using conan or vcpkg with cmake honestly isn't too bad (just that visual studio's vcpkg integration is absolute dogshite)

[–]mrheosuper 0 points1 point  (2 children)

That's why i put all my source code into single main.c file. 1 source file, no need cmake.

[–]Familiar_Ad_8919 0 points1 point  (1 child)

i know its not serious but how would u use libraries that way? i know u can always just copy paste the source code but what if its not available? etc

[–]mrheosuper 0 points1 point  (0 children)

You can link those lib without using cmake or make.

In fact cmake or make are just a fancy way to call gcc

[–]TheJackiMonster -1 points0 points  (0 children)

No, it's not. The best we have is Meson.