"The C and C++ compilation model is inherently more complex than almost any other language in use today [...] it is built to meet extremely high and strange demands."
Ok, I'm always open to new build systems specifically tailored for C/C++ development. Let's keep reading...
"If you opt-in to have your library built by dds, you forgoe customizability in favor of simplicity and ease."
Hmm... but you just said the C/C++ build space is one of the most complex ones... how can you cater to this market with a one-size fits all approach? Let's keep reading:
"dds Is not Made for Complex Applications"
and
"Your Code Should Be Changed Before dds Should Be Changed"
Ehh... seems like it would only fit a small portion of real-word use cases.
For example, let's say I have a few support libraries that I can package using dds. Eventually I need to integrate these libraries with an actual application. What do I do then? As they said, dds is not made to support complex applications. Maybe my application is just a PITA to build with dds. What now? Have a separate build system just for the application? No, thanks.
Having a simple, coherent approach to building is definitely a feature. But being inflexible for the sake of it is definitely not. There's way too many options out there already.
> At some point you just bite the bullet and learn to use CMake+conan
I should add that even so the only thing that Conan brings to the table is convenience, for the lazy like me. All anyone really needs is cmake, and spend 10 minutes learning how to use cmake and how to ingest third-party packages.
I really like there's no need for a build file. The file hierarchy and filenames holds that information for you. Neat.
Another tool that I think does not get enough attention and that I really like is Xmake (and Xrepo, its package manager companion).
What is great about it is that the build file is a lua file so you don't need to learn another DSL and you can very quickly get to work. It also claims to be just as fast as ninja while not requiring you to learn either Cmake or Meson.
https://xmake.io/
There’s no DSL. The build system just has a primitive text-based IPC mechanism over stdout/stdin that the rules write to/read from (ie use whatever language you want) and it has hermetic build support. The only stuff baked in is file discovery/watching and executable linking.
9 comments
[ 3.8 ms ] story [ 32.5 ms ] threadOk, I'm always open to new build systems specifically tailored for C/C++ development. Let's keep reading...
"If you opt-in to have your library built by dds, you forgoe customizability in favor of simplicity and ease."
Hmm... but you just said the C/C++ build space is one of the most complex ones... how can you cater to this market with a one-size fits all approach? Let's keep reading:
"dds Is not Made for Complex Applications"
and
"Your Code Should Be Changed Before dds Should Be Changed"
Ehh... seems like it would only fit a small portion of real-word use cases.
For example, let's say I have a few support libraries that I can package using dds. Eventually I need to integrate these libraries with an actual application. What do I do then? As they said, dds is not made to support complex applications. Maybe my application is just a PITA to build with dds. What now? Have a separate build system just for the application? No, thanks.
Having a simple, coherent approach to building is definitely a feature. But being inflexible for the sake of it is definitely not. There's way too many options out there already.
I should add that even so the only thing that Conan brings to the table is convenience, for the lazy like me. All anyone really needs is cmake, and spend 10 minutes learning how to use cmake and how to ingest third-party packages.
Another tool that I think does not get enough attention and that I really like is Xmake (and Xrepo, its package manager companion). What is great about it is that the build file is a lua file so you don't need to learn another DSL and you can very quickly get to work. It also claims to be just as fast as ninja while not requiring you to learn either Cmake or Meson. https://xmake.io/
There’s no DSL. The build system just has a primitive text-based IPC mechanism over stdout/stdin that the rules write to/read from (ie use whatever language you want) and it has hermetic build support. The only stuff baked in is file discovery/watching and executable linking.
[1] https://github.com/capnproto/ekam