21–30 of 58 posts
Earlier quoted context omitted.
Begin by throwing the language away. Provide a tool that converts existing CMake scripts to the new, sane language. Use an established programming language for the new language.
That's basically what CMake already attempted to do: be a sane alternative to figuring out the madness of autoconf and Makefiles.
All these CMake improvements are the best example of optimising into a local minimum I have ever seen in SWE
Good phrasing! I’m just a hobbyist so I don’t get very involved but what would you suggest as an alternative maximum?
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.
Earlier quoted context omitted.
Begin by throwing the language away. Provide a tool that converts existing CMake scripts to the new, sane language. Use an established programming language for the new language.
CMake semantics except expressed in Python scripts somehow sounds even worse.
It was originally part of Bazel but it is used in other tools, and there are multiple implementations.
Earlier quoted context omitted.
Good phrasing! I’m just a hobbyist so I don’t get very involved but what would you suggest as an alternative maximum?
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 b…
My experience with build systems is that, by going through the pain of trying to implement your own build system with some of the same desiderata as Bazel (reliability, performance), you end up independently discovering the same features Bazel has (like the purposefully limited scripting system). Going in the opposite direction seems like the best way to purposefully design a bad build system, but maybe I misunderstand what your goals are here?
Earlier quoted context omitted.
That's basically what CMake already attempted to do: be a sane alternative to figuring out the madness of autoconf and Makefiles.
The language itself is, in many ways, worse than the shell scripts it replaced with autoconf.
But CMake probably will get you a program that compiles cross-platform within an hour or two, even for a novice. Autotools probably won't do that for you.
Earlier quoted context omitted.
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 b…
Are you being serious, or is this an elaborate joke? My experience with build systems is that, by going through the pain of trying to implement your own build system with some of the same desiderata as Bazel (reliability, performance), you end up independently discovering the same features Bazel has (like the purposefully limited scripting system). Going in the opposite direction seems like the best way to purposeful…
My goal is to make a build system that the majority of people don't hate.
I understand your concerns about a fully-powerful system. I know that's why Bazel is a favorite.
But Nix has the same reliability with a full Turing-complete language, and I feel like I can recover the performance by using C instead of Java.
In addition, I understand the purpose of limited languages in build systems. I really do.
The first public release of my build system (the MVP) will have the ability to restrict the power of the language, and it will do so by default because limiting power when working with other people is noice. [1]
You may ask why I make a point of power if my own language will be hobbled by default. Because users will still be able to remove the hobble if needed. And sometimes, it will be needed.
But I'll still go above and beyond; not only will users be able to choose between a restricted language or a powerful one, they'll be able to choose how powerful the language needs to be.
Only need a POSIX Makefile replacement? That's the default. Need if statements, but only if statements? Got you covered. Need functions? No problem. Need loops? Just say the word. No dynamic build stuff needed? No worries needed. Wanna go full Palpatine? Yes, Master.
In other words, I hear you, and you are right for the vast majority of cases. But for that other minority of cases, power must exist, and there is no alternative, so it will be available.
This is related to Joel Spolsky's assertion that while everybody only uses 20% of the features, nobody uses the same 20% [2]:
> A lot of software developers are seduced by the old “80/20” rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.
> Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release “lite” word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the “word count” feature which they need because most journalists have precise word count requirements, and it’s not there, because it’s in the “80% that nobody uses,” and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can’t use this...thing ’cause it won’t count my words.
I hope that makes sense. And thank you for clarifying in your second paragraph.
[1]: https://youtube.com/watch?v=GGYpESpbHis
[2]: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
Everything You Never Wanted to Know About CMake - https://news.ycombinator.com/item?id=19070733 - Feb 2019 (87 comments)
Without CMake, from powershell, you can do something like `& "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\Launch-VsDevShell.ps1" -VsInstallationPath:"C:\Program Files\Microsoft Visual Studio\2022\Community" -Arch:amd64 -HostArch:amd64 -SkipAutomaticLocation` and it works well enough. I usually provide that oneliner as a vs2022ce-x64-x64.ps1 script, and just note in the README that users can adapt it to their system/needs.
Also of note is the amazing portable-msvc.py by the one and only Mārtiņš Možeiko : https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cd...
It downloads the compiler toolchain and nothing more, and writes a setup.bat with no conditional logic. It was trivial for me to adapt to write a setup.ps1 also. Compare the size of the result, vs my attempt to have a minimal toolchain using the Visual Studio Installer.
1.3G msvc
4.2G C:/Program Files/Microsoft Visual Studio/2022/Community
I don't recommend projects to use it directly, it's just an excellent resource to point people towards.
Earlier quoted context omitted.
Are you being serious, or is this an elaborate joke? My experience with build systems is that, by going through the pain of trying to implement your own build system with some of the same desiderata as Bazel (reliability, performance), you end up independently discovering the same features Bazel has (like the purposefully limited scripting system). Going in the opposite direction seems like the best way to purposeful…
Deadly serious. My goal is to make a build system that the majority of people don't hate. I understand your concerns about a fully-powerful system. I know that's why Bazel is a favorite. But Nix has the same reliability with a full Turing-complete language, and I feel like I can recover the performance by using C instead of Java. In addition, I understand the purpose of limited languages in build systems. I really do…
Bazel’s BUILD.bazel scripts are restricted, but that part is the middle of a “sandwich” which handles the 90% use cases. If you want unfettered execution, you get that in the repository rule phase and the actual build actions (the two slices of bread in our sandwich). This allows you to define build rules dynamically (as long as you can do it before the main part of the build runs) and allows you to run arbitrary code in your build actions (as long as you specify a superset of the inputs and output, and your outputs are disjoint).