DDS: Build and library management tool for C, C++(vector-of-bool.github.io)
vector-of-bool.github.io
DDS: Build and library management tool for C, C++
https://vector-of-bool.github.io/docs/dds/index.html
9 comments
At some point you just bite the bullet and learn to use CMake+conan
> 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 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/
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/
Have you come across the Ekam build system? [1]
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
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
Never heard of it. Looks interesting thanks.
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.