[HN Gopher] DDS: Build and library management tool for C, C++
___________________________________________________________________
DDS: Build and library management tool for C, C++
Author : oumua_don17
Score : 21 points
Date : 2022-01-29 00:33 UTC (1 days ago)
(HTM) web link (vector-of-bool.github.io)
(TXT) w3m dump (vector-of-bool.github.io)
| cassepipe wrote:
| 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/
| vlovich123 wrote:
| 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
| elteto wrote:
| "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.
| LeSaucy wrote:
| At some point you just bite the bullet and learn to use
| CMake+conan
| conanagree wrote:
___________________________________________________________________
(page generated 2022-01-30 23:01 UTC)