> I would definitely write (or at least read) a few Bazel rules before writing a new build system that improves on it!
You have a point there; I didn't because everything I've seen is that people like the results of Bazel, but they hate writing rules, so Bazel rules seemed like something to not emulate.
But point taken.
And thank you for the explanation. It seems providers allow for multiple outputs on a target. My build system allows that, but bundling such outputs together is a good idea that I need to add.
My build system will actually have a command-line option to reverse the dependency resolution. Instead of building a given target, updating its dependencies as necessary, it will build the default target(s), marking the files given on the command-line as "changed" and resolving dependents up to the default target(s).
This will mean that building the "current file" will be a simple command-line switch that can be part of the file generated for that IDE.
But yes, I'm going to put in a lot of work to make IDE's work as smoothly as possible.
Yes, I'm a solo dev and not looking for contributors. My style is too eccentric to accept outside contributions.
Funny you should mention Bazel and Buck; I'm coming for them too! I'm also coming for Nix; I want its advantages to be easily accessible for mere mortals.
I think I can do better alone than those teams have because they have all made assumptions that weren't great. I'm learning from their mistakes.
Also, UX matters, and I'm putting a lot of effort into that.
But the other reason is that if you do Nix right, the capabilities of Bazel and Buck just appear.
> That's the critical selling point of CMake in my estimation. When I'm on Windows, I can generate a Visual Studio project and use its excellent debugger and code analysis tools. When I'm on Mac, I can generate an XCode project. Or a CLion project, or Makefiles, or...
I've already addressed some of this in another comment ([1]), but you bring up more points, so I'll address it here.
CMake's model forces it to generate build files for other build systems. The better model does not force the build system to, but it also does not preclude doing so.
Separately from actually running a build (and that's important), my build system will be capable of generating files for VS, XCode, and other IDE's, but the files it generates will simply tell the IDE's how to integrate with my build system by telling them how to call it with the correct build profile. And yes, it will generate multiple possible build profiles, allowing VS users to select the solution the want to build from within VS.
But this means that my build system will not only integrate better with IDE's than CMake, it will still retain full control of actual builds.
This includes using debuggers and analysis tools, by the way. I wouldn't consider my work done on IDE integration until all of that is as easy as possible, and definitely as easy as CMake.
> Isn't that exactly what an INTERFACE library is for?
Maybe? It might be enough. At first glance (and I fully acknowledge that I could be wrong here), it seems like CMake expects the "target" to be a library of some sort. That's not the sort of thing I would personally want.
I would want to be able to depend on any target for any target.
But again, I could be wrong. I've never been able to understand the CMake docs.
Sure, but doing so doesn't mean that the generating build system had to have the same model as CMake.
Here's how my build system will do it: the programmer will list default build profiles. Then the build system will generate Visual Studio or XCode files that include all of those default build profiles, but those VS or XCode files will simply call my build system with the correct build profile.
Thus, when a build is run from VS or XCode, my build system is still in full control.
In essence, instead of generating build files for use by other build systems, my build system will generate files to tell VS and XCode how to call my build system. It will tell VS and XCode how to integrate it.
Disclaimer: author of a build system that will compete against CMake when it's released.
I'm not impressed, for two reasons:
* Backwards compatibility for the CMake language is not desirable. It would be better to allow files to be translated to the new language completely. Sure, CMake could support having files in the old language and files in the new language, but the CMake language is so bad that a break from it is the best path forward.
* The CMake language is not the only drawback to CMake, unlike the claims in the presentation. CMake's model is hamstrung as well, in several ways.
Here are some ways in which the CMake model is hamstrung:
* Generating a build file for another build system. This means that CMake always gives up control of the build. It can only tell the other build system the dependency graph and then sit back and watch. It can't regulate the build itself.
* No dynamic dependencies. If you need dynamic dependencies, you need to call into CMake to generate a new and separate build file for the second build system and then call that. And because the two build files that CMake generated don't know anything about each other, it's hard to regulate the use of computing resources between them; you either have to complete the one and start the other, or you risk over-extending on your computing resources.
* No way to generate a target that doesn't call an outside process. More generally, the only way to generate a target (unless my CMake knowledge is old) is to have the second build system create a child process. This is strictly less powerful than having the same scripting language available during configure also available in targets. For example, LaTeX is only properly built with a loop that checks for a fixed point. If you can't loop in your target, you have to use an outside bash script or something of the sort to make up for it.
* No way to have targets that do not generate files and have other targets depend on those targets. If a target does not generate a file, CMake does not know how to make other targets depend on it (unless my CMake knowledge is old).
* The model of "configure in Turing complete language and then build" also means that configuring often has to happen more than once before a build. You see this if you use `ccmake`: you configure, and new options appear. You set the options and configure again. More options might appear. Using plain `cmake` hides this by using defaults, but that just means the user might end up with a build they didn't want because they didn't get a chance to set all of the options they might care about.
> Your comments in this thread were doing ideological battle on a classic flamewar battlefront. You even used the word "fighting" to describe what you were doing. Surely you can understand how lines like ""wokeists" have caused so much damage to this country" and "The community you love has done damage to [...] society" are flamebait?
No, not really. I was answering certain accusations with my opposing opinions.
Unfortunately, I can't understand where a person is coming from if I don't understand their definitions of certain terms, and I can't understand your definitions of flamewar and flamebait.
> If you get into back-and-forths with an opposing user around that kind of thing, you're perpetuating flamewar. This is clearly not curious conversation.
I guess I misunderstand the purpose of HN because this line of yours makes it seem (to me) like I cannot debate political things at all, or rather, certain topics (does "around that kind of thing" means political things?), but that doesn't seem right either.
> However, there are many ways to lower the expected value of a thread, and flamebait/flamewar is just one of them.
That's why I think putting the lowering of the expected value of a thread into the guidelines is the right choice: it covers more situations.
> I think it's important to be specific.
I have shut off the discussion you didn't like, but it would be helpful to me if you were more specific about what you see as flamebait and flamewar. If I understand what you want me to not do, I'll avoid it, but I can't avoid something I'm unclear on. I also don't like self-censoring more than necessary (that is what the posted article was about, after all).
However, I expect that you're busy and won't be able to answer me, so extra self-censoring might be what I have to do. It makes me sad, though; I felt like HN was one place where I didn't have to do that, and now, it does not.
Edit: one thing that I could consider is trying to not answer every accusation that I'm a terrible person. Ten years ago, my Christian faith would not be attacked so openly. Now, people consider me a terrible person for believing those same things, and I find myself defending my faith a lot, albeit indirectly.
I will try to do that less on HN at least. Would that be what you are doing of me?
Please define "perpetuate flamewars" for me because I don't understand how you use that phrase.
I didn't attack the messenger, which is the definition of that phrase I usually use. I also very carefully only addressed the points the other person made.
Edit: also, I have read your comment from a long time ago about the expected value of a discussion. Perhaps that is the definition you personally use? As in, you consider any comment to be "perpetuating flamewars" once it is made in a discussion with a lower expected value than you want to accept.
I can't argue with that definition; in fact, I would accept it wholeheartedly, but (and this is just a suggestion) it might be better to make that the site guidelines, as well as to adjust your wording when you tell people to knock it off as you just did.
For example, if you came to me and said, "The expected value of this discussion is lower than the value that this site can accept, so please stop this discussion here," I think I personally would take it much better than being accused of perpetuating flamewars. And I would be more likely to obey.
You can still ban people for not obeying such requests too. I think you should.
Guilt by association is a logical fallacy. That is not a good argument.
The community you love has done damage to the society you depend on. I have no viciousness towards any one of them except where they insist on remaking society in their image to the detriment of all others.
Ignorance through force of law would apply if the history were factual. But it's not. Preventing bad ideas from being taught is the opposite of codifying ignorance.
And like many others, I can also look like I'm experiencing other emotions because I am. But I have a resting angry face, and it gets more extreme the more deeply I am thinking.
My wife works in a company with programmers, and they keep their webcams off during virtual meetings because, "We don't want people to see our thinking faces." Yes, that is an exact quote.