3 ms·

Generally speaking, what killed C++/C for me is the absolute insanity that comes with it's build systems/third party dependency management. I feel like the not

Generally speaking, what killed C++/C for me is the absolute insanity that comes with it's build systems/third party dependency management. I feel like the notoriety that C++ gets for it's absurd complexity comes not from variadic template metaprogramming/rvalue references/unique_ptr or whatever, but the absolutely humongous effort needed to understand automake/CMake/autotools just to build other people's code (god forbid on a different platform than the original author).

adamdusty 5y ago
The build system for zig is essentially the same as CMAKE just in Zig and entirely undocumented.
- rofrol 5y ago
  - https://ziglang.org/learn/overview/#zig-build-system https://ziglang.org/learn/overview/#zig-build-system - https://ziglearn.org/chapter-3/#zig-build https://ziglearn.org/chapter-3/#zig-build - https://zig.news/xq/zig-build-explained-part-1-59lf https://zig.news/xq/zig-build-explained-part-1-59lf - https://dev.to/mattnite/weaning-zig-off-of-git-submodules-1-3jen https://dev.to/mattnite/weaning-zig-off-of-git-submodules-1-... - https://dev.to/fabioarnold/setup-zig-for-gamedev-2bmf https://dev.to/fabioarnold/setup-zig-for-gamedev-2bmf
pjmlp 5y ago
I just build a VS solution, call MSBuild, install dependencies via NuGET/vcpkg and be done with it. And even better since they support binary libraries, I can focus on my own code instead of building the foundations first.
deleted 5y ago
[deleted]
slimsag 5y ago
I totally 100% agree. "Getting started" with a C/C++ project is a huge pain and IMO where most people get stuck and give up on their weekend project. I'm working on a game engine in Zig[0], and I've been able to package up GLFW, write a build.zig file that `git clone`s all of the third-party system dependencies so that anyone can just: const glfw = @import("glfw/build.zig"); ... lib.addPackagePath("glfw", "glfw/src/main.zig"); glfw.link(b, lib, .{}); And have GLFW building (and cross-compiling!) for their project, without installing anything other than Zig and Git. No XCode. No `apt-get install ...`. Nothing. Just `zig` and `git` binaries. Zig is the C compiler and builds the GLFW source, and I have repositories with the required prebuilt system libs for cross compilation. [0] https://github.com/hexops/mach https://github.com/hexops/mach
PaulDavisThe1st 5y ago
> the absolute insanity that comes with it's build systems/third party dependency management. Well yes, that would kill me too, if I actually expected the language to come with a single blessed dependency that addresses functionality <Foo>, that I will never want or need to patch the blessed dependency, and that there would be only one way to actually build a program or library. But it doesn't kill me because I don't expect either of those things. The dependency stack for my (21 year old) project consists of 86 3rd party libraries that on an x86_64 platform take up about 2GB after compilation. This is intimidating and sometimes painful, but I don't find it insane in any way. We have patches for a half-dozen of the deps that will never make it upstream and we have to be sure that we compile the libraries in the precise way that we need them (for example, we require the thread-safe version of libfftw, not the regular version).
travisgriggs 5y ago
I'd say both. C++ is so insanely complicated at times with the various things you mention. And every release it just seems to get worse, because while "nice to have features" are added, the old stuff doesn't go away, and the syntactic gymnastics they have to go through to get it all to coexist are the programming language to who's on first. But the stack of stuff it takes you supposedly need to get stuff to compile is often insane. On one project I demonstrated that just find . | grep ".c$" | xargs gcc ... and a final link ran significantly faster than the mass of recursive nested/fake/etc makefiles that were supposed to speed up the compiles by doing dependency computations. I remember showing someone the basic "we turn the .c files into .o files, and then we make a second pass to link 'em" and they were like "really? that's all there is to compiling a C program?" The real straw for me when I was contributing to the Cairo project was recognizing I was going to have understand this stuff more, and so I sat down and read the Make manual: 16 chapters. Now I need to understand Automake, read the manual: 26 chapters. And then Autoconf: 21 chapters. It was like it was just spinning bigger and bigger.

adamdusty 5y ago

The build system for zig is essentially the same as CMAKE just in Zig and entirely undocumented.

rofrol 5y ago
- https://ziglang.org/learn/overview/#zig-build-system https://ziglang.org/learn/overview/#zig-build-system - https://ziglearn.org/chapter-3/#zig-build https://ziglearn.org/chapter-3/#zig-build - https://zig.news/xq/zig-build-explained-part-1-59lf https://zig.news/xq/zig-build-explained-part-1-59lf - https://dev.to/mattnite/weaning-zig-off-of-git-submodules-1-3jen https://dev.to/mattnite/weaning-zig-off-of-git-submodules-1-... - https://dev.to/fabioarnold/setup-zig-for-gamedev-2bmf https://dev.to/fabioarnold/setup-zig-for-gamedev-2bmf

pjmlp 5y ago

I just build a VS solution, call MSBuild, install dependencies via NuGET/vcpkg and be done with it. And even better since they support binary libraries, I can focus on my own code instead of building the foundations first.

deleted 5y ago

[deleted]

slimsag 5y ago

I totally 100% agree. "Getting started" with a C/C++ project is a huge pain and IMO where most people get stuck and give up on their weekend project. I'm working on a game engine in Zig[0], and I've been able to package up GLFW, write a build.zig file that `git clone`s all of the third-party system dependencies so that anyone can just: const glfw = @import("glfw/build.zig"); ... lib.addPackagePath("glfw", "glfw/src/main.zig"); glfw.link(b, lib, .{}); And have GLFW building (and cross-compiling!) for their project, without installing anything other than Zig and Git. No XCode. No `apt-get install ...`. Nothing. Just `zig` and `git` binaries. Zig is the C compiler and builds the GLFW source, and I have repositories with the required prebuilt system libs for cross compilation. [0] https://github.com/hexops/mach https://github.com/hexops/mach

PaulDavisThe1st 5y ago

> the absolute insanity that comes with it's build systems/third party dependency management. Well yes, that would kill me too, if I actually expected the language to come with a single blessed dependency that addresses functionality <Foo>, that I will never want or need to patch the blessed dependency, and that there would be only one way to actually build a program or library. But it doesn't kill me because I don't expect either of those things. The dependency stack for my (21 year old) project consists of 86 3rd party libraries that on an x86_64 platform take up about 2GB after compilation. This is intimidating and sometimes painful, but I don't find it insane in any way. We have patches for a half-dozen of the deps that will never make it upstream and we have to be sure that we compile the libraries in the precise way that we need them (for example, we require the thread-safe version of libfftw, not the regular version).

travisgriggs 5y ago

I'd say both. C++ is so insanely complicated at times with the various things you mention. And every release it just seems to get worse, because while "nice to have features" are added, the old stuff doesn't go away, and the syntactic gymnastics they have to go through to get it all to coexist are the programming language to who's on first. But the stack of stuff it takes you supposedly need to get stuff to compile is often insane. On one project I demonstrated that just find . | grep ".c$" | xargs gcc ... and a final link ran significantly faster than the mass of recursive nested/fake/etc makefiles that were supposed to speed up the compiles by doing dependency computations. I remember showing someone the basic "we turn the .c files into .o files, and then we make a second pass to link 'em" and they were like "really? that's all there is to compiling a C program?" The real straw for me when I was contributing to the Cairo project was recognizing I was going to have understand this stuff more, and so I sat down and read the Make manual: 16 chapters. Now I need to understand Automake, read the manual: 26 chapters. And then Autoconf: 21 chapters. It was like it was just spinning bigger and bigger.