What does HackerNews think of gdb-dashboard?

Disclaimer: I'm making a competing build system.

I won't tell you specific build systems, but I will tell you what to look for.

Look for power. Unlimited power. [1]

Usually, this means a few things:

1. The build system uses a general-purpose language, even if the language needs features to be added.

2. The build system does not reduce the power of the general-purpose language. For example, say it starts with Python but prohibits recursion. In that case, you know it is not unlimited power. Looking at you, Starlark.

3. The build can be dynamically changed, i.e., the build is not statically determined before it even begins.

4. Each task has unlimited power. This means that the task can use a general-purpose language, not just run external processes.

5. And there has to be some thought put it in user experience.

Why are these important? Well, let's look at why with CMake, which fails all of them.

For #1, CMake's language started as a limited language for enumerating lists. (Hence, CMakeLists.txt is the file name.) And yet, it's grown to be as general-purpose as possible. Why? Because when you need an if statement, nothing else will do, and when you need a loop, nothing else will do.

And that brings us to #2: if CMake's language started limited, are there still places where it's limited? I argue yes, and I point to the article where it says that your couldn't dynamically call functions until recently. There are probably other places.

For #3, CMake's whole model precludes it. CMake generates the build upfront then expects another build system to actually execute it. There is no changing the build without regenerating it. (And even then, CMake did a poor job until the addition of `--fresh`.) A fully dynamic build should be able to add targets and make others targets depend on those new targets dynamically, among other things.

For #4, obviously CMake limits what tasks can do because Ninja and Make limit tasks to running commands.

As another example, to implement a LaTeX target, you technically need a while loop to iterate until a fixed point. To do that with Make and Ninja, you have to jump through hoops or use an external script that may not work on all platforms.

CMake obviously fails #5, and to see how much other build systems fail it, just look for comments pouring hate on those build systems. CMake fails the most, but I haven't seen one that passes yet.

As an example, CMake barely got a debugger. Wow! Cool! It's been 20 years! My build system will have a debugger in public release #2 (one after the MVP) that will be capable of outputting to multiple TTY's like gdb-dashboard. [2] They should have had this years ago!

Should other comments suggest specific build systems, like the one that suggested Bazel, judge them by this list. Some will be better than others. None will pass everything, IMO, which is why I'm making my own.

[1]: https://youtube.com/watch?v=Sg14jNbBb-8

[2]: https://github.com/cyrus-and/gdb-dashboard

Try gdb-dashboard: https://github.com/cyrus-and/gdb-dashboard

Try GDB Dashboard, it makes gdb much easier to use:

https://github.com/cyrus-and/gdb-dashboard

There's also Voltron which works with both gdb and lldb (amongst others):

https://github.com/snare/voltron

I'm not sure exactly what debugger is used, but gdb dashboard can be set up in a similar way. It's just stepping through instructions and viewing the registers and some memory regions.

https://github.com/cyrus-and/gdb-dashboard

Though any debugger should be able to give the same information (including just plain gdb).