the fact that other people use it is what makes cmake better. configuring dependencies is the main point of build systems, and with cmake you just type find_package and forget about it because everybody has a cmake build script.
No better argument it needed. The current state of build systems in c++ is absolutely horrendous, and it's largely because the people who write build systems are the ones who are only talented enough to write build systems.
Someone should pay a PhD 1MM and get the problem solved for good. It would be a much more economical solution than having the thousands of code monkeys currently working on the problem continue to frick around for the next two decades, getting no closer to a working solution.
>Try Bevy hello_world example >Pulls 20 GB of dependencies >Make new Bevy project >Write some code >cargo build >Another set of 20 GB dependencies
Thanks but I'm sticking with C++
Shitting up your storage for shits and giggles is not a flex anon.
1 month ago
Anonymous
It's not shits and giggles, it's to solve the dependency and build system hell that is the entire C and C++ ecosystem. I'd much rather use some of my plentiful disk space than have to use cmake.
Use Meson.
I forked a project that determines the install directory of an xdg portal file in meson using get_option('datadir') which is '/usr/share' on arch which is good, but is '/usr/local/share' on ubuntu, which does not work. Would meson people yell at me if I just hardcode the one that works instead of doing it the proper meson way by calling functions?
1 month ago
Anonymous
Why do people say there's dependency hell for c/c++? Is it mostly proprietary projects that have these issues?
>Bevy hello_world >I imported an entire game engine on my hello world file, wtf why is it so huge
gee anon i don't know. Maybe its because like trying to use unreal engine for a text adventure game.
My success rate of compiling projects that use CMake is probably under 30% throughout my computer usage career
'make' on the other hand worked most of the time
Build systems for large C and C++ projects inevitably become either completely unmaintainable and break if you move a single file, or become their own large projects with DSLs. I prefer CMake over Autotools, cause at least I have some sort of fricking clue what a CMake config file does, I have no fricking clue what autotools gets up to
make, autotools, cmake, etc. try to emulate shell scripts in their syntax and semantics, and they are all turing complete. the way these tools work is very unintuitive for c/c++ programmers so most people use their ide or some other tool to auto-generate them, but this only worsens the problem because then you have to decipher the auto-generated build scripts
meson is more like what a c programmer would expect from a building system, there are no "tricks" or hidden control flow. for example, to compile a simple executable, you do something like this:
project('name', 'cpp')
src = files (
'main.cpp',
'other.cpp',
)
inc = include_directories(
'include/',
)
dep = [
dependency('somelibrary'),
]
executable(
'out_bin',
sources : src,
dependencies : dep,
include_directories : inc,
)
you can probably guess what this does, even if you have never used meson before
>declarative syntax
As God intended. I hate CMake so much because the order of instructions matters. Build system should describe how to reach Z starting from some point A, not be a fricking programming language of its own.
Damn, that almost looks like something I would bother with.
Cmake was ok once you spent a week figuring out all the tricks and navigating their bullshit documentation, but once you do something else for a year and come back it's learning everything all over again.
moron question, what does autoconf give you over handrolled makefiles? the correct gcc flags for obscure platforms that stopped being supported in 1995?
I just use a series of bash scripts which run the commands I need. There's no caching and no parallel builds. Each time I run ./go.sh, all objects from last time are thrown away and all source files are rebuilt one-by-one.
The trick is to use a compiler that's fast enough for this to be a non-issue. For C I recommend the bleeding-edge ("mob") version of tinycc. It's a single-pass, non-optimising compiler that's fast enough to render build systems obsolete.
(You can always use a different compiler for the release build if you feel the need.)
When I need to use large third-party libraries that are a pain to build, my usual solution is to build them once and just check the resulting DLL into source control. Works great on Windows. Not conventional on Linux but I don't really care about the Linux build very much, as long as it works on my machine.
Also, wherever possible I include headers by relative path to avoid needing to set custom include dirs:
// Yes
#include "../third_party/sdl2/include/SDL.h"
// No
#include <SDL.h>
That's usually enough for my editor to offer basic autocomplete etc without it needing to understand the whole build process.
All I know as someone who has compiled thousands of programs from source, but never written a serious project in C/C++, is that every time I compiled a project using CMake, it built beautifully and ran beautifully.
Whereas automake stuff was frequently a morass of cryptic error messages and struggling with library and header paths
it would strengthen your argument if you explained why and provided a better altenrative candidate
almost anything is better aside from plain makefiles. you don't use cmake because it's good you use cmake because other people use cmake
the fact that other people use it is what makes cmake better. configuring dependencies is the main point of build systems, and with cmake you just type find_package and forget about it because everybody has a cmake build script.
No better argument it needed. The current state of build systems in c++ is absolutely horrendous, and it's largely because the people who write build systems are the ones who are only talented enough to write build systems.
Someone should pay a PhD 1MM and get the problem solved for good. It would be a much more economical solution than having the thousands of code monkeys currently working on the problem continue to frick around for the next two decades, getting no closer to a working solution.
Same, OP.
GNU Make is best for simple things.
Do not do complicated things, not worth it.
That didn't take long
I thought the same until I learned CMake. I'm guessing you don't know how to use CMake. (Copy pasting snippets from stack overflow doesn't count)
In rust you just cargo build
>Try Bevy hello_world example
>Pulls 20 GB of dependencies
>Make new Bevy project
>Write some code
>cargo build
>Another set of 20 GB dependencies
Thanks but I'm sticking with C++
Storage is cheap. Are you poor or something?
Shitting up your storage for shits and giggles is not a flex anon.
It's not shits and giggles, it's to solve the dependency and build system hell that is the entire C and C++ ecosystem. I'd much rather use some of my plentiful disk space than have to use cmake.
I forked a project that determines the install directory of an xdg portal file in meson using get_option('datadir') which is '/usr/share' on arch which is good, but is '/usr/local/share' on ubuntu, which does not work. Would meson people yell at me if I just hardcode the one that works instead of doing it the proper meson way by calling functions?
Why do people say there's dependency hell for c/c++? Is it mostly proprietary projects that have these issues?
yes im poor and im from europe
Cargo just works.
You can't add more dependencies by writing some code, larper.
>Bevy hello_world
>I imported an entire game engine on my hello world file, wtf why is it so huge
gee anon i don't know. Maybe its because like trying to use unreal engine for a text adventure game.
My success rate of compiling projects that use CMake is probably under 30% throughout my computer usage career
'make' on the other hand worked most of the time
Just use cargo 🙂
Build systems for large C and C++ projects inevitably become either completely unmaintainable and break if you move a single file, or become their own large projects with DSLs. I prefer CMake over Autotools, cause at least I have some sort of fricking clue what a CMake config file does, I have no fricking clue what autotools gets up to
>he doesn't take 5 shits every day
toilets are cheap..
Use Meson.
Redpill me on meson. Why is it special?
it's the latest meme build system.
use make if you're working in a small team or a project that only runs in one environment, cmake if you're medium, bazel if you're operating at scale.
make, autotools, cmake, etc. try to emulate shell scripts in their syntax and semantics, and they are all turing complete. the way these tools work is very unintuitive for c/c++ programmers so most people use their ide or some other tool to auto-generate them, but this only worsens the problem because then you have to decipher the auto-generated build scripts
meson is more like what a c programmer would expect from a building system, there are no "tricks" or hidden control flow. for example, to compile a simple executable, you do something like this:
project('name', 'cpp')
src = files (
'main.cpp',
'other.cpp',
)
inc = include_directories(
'include/',
)
dep = [
dependency('somelibrary'),
]
executable(
'out_bin',
sources : src,
dependencies : dep,
include_directories : inc,
)
you can probably guess what this does, even if you have never used meson before
>declarative syntax
As God intended. I hate CMake so much because the order of instructions matters. Build system should describe how to reach Z starting from some point A, not be a fricking programming language of its own.
Damn, that almost looks like something I would bother with.
Cmake was ok once you spent a week figuring out all the tricks and navigating their bullshit documentation, but once you do something else for a year and come back it's learning everything all over again.
you know you're using a low level language when you need a whole other language just to compile it
>I HATE HATE HATE HATE build systems
Maybe you haven't tried automake. Using CMake looks like heaven compared to automake.
cmake is honestly one of the better ones, it's relatively straightforward, unless you're a brainlet
>t. c++ dev
use the zig build system to build your C
Looks interesting. Thanks anon.
What about xmake?
Why must compiling shit be so difficult? I tried using CMake but it just kept complaining about MS Visual C even though I have it installed.
moron question, what does autoconf give you over handrolled makefiles? the correct gcc flags for obscure platforms that stopped being supported in 1995?
I just use a series of bash scripts which run the commands I need. There's no caching and no parallel builds. Each time I run ./go.sh, all objects from last time are thrown away and all source files are rebuilt one-by-one.
The trick is to use a compiler that's fast enough for this to be a non-issue. For C I recommend the bleeding-edge ("mob") version of tinycc. It's a single-pass, non-optimising compiler that's fast enough to render build systems obsolete.
(You can always use a different compiler for the release build if you feel the need.)
When I need to use large third-party libraries that are a pain to build, my usual solution is to build them once and just check the resulting DLL into source control. Works great on Windows. Not conventional on Linux but I don't really care about the Linux build very much, as long as it works on my machine.
Also, wherever possible I include headers by relative path to avoid needing to set custom include dirs:
// Yes
#include "../third_party/sdl2/include/SDL.h"
// No
#include <SDL.h>
That's usually enough for my editor to offer basic autocomplete etc without it needing to understand the whole build process.
All I know as someone who has compiled thousands of programs from source, but never written a serious project in C/C++, is that every time I compiled a project using CMake, it built beautifully and ran beautifully.
Whereas automake stuff was frequently a morass of cryptic error messages and struggling with library and header paths
I just use C and Makefile.
It's simple.
I unironically enjoy Epic Games' build system