3 ms·

>I don't need a make, and neither should redo. I didn't meant to imply that you or redo needs a make. Just that for something like autotools or cmake, there's

>I don't need a make, and neither should redo. I didn't meant to imply that you or redo needs a make. Just that for something like autotools or cmake, there's a lot of abstraction required just to get things to work. Or you can bundle things or you can write your own things but the point is, it's a lot of work. >I don't think it's a waste of effort. People on Windows deserve a good build system too. In fact, not having a good one means that they are dependent on Microsoft. I'd like to help them reduce that dependence. Right, but as I point out, microsoft already took care of that by giving windows users WSL. >It's not hard to get make to do that. See [1] and [2]. Yes I know what it takes, but if you don't think this is horrifically over-complicated then I don't know what to tell you. Instead of using implicit rules with target specific overrides you've made it slightly less boilerplaty by making it less scalable and expanding the entire build command for a specific target. I still think this is too much boilerplate and noise. >Yes, but however it's done, it's still easiest in a self-contained system, IMO. I think it may be easiest to implement (just like any complicated solution is easier to implement than a simple one) but I don't think it's a good goal for a build system. Complexity isn't free, even if it has a cheaper initial cost. >The build system should carefully control the environment. In fact, it should make sure the environment is empty. (There are details, but in general...) That's the biggest thing to make sure the compiler does not act weird. I disagree, you would also need to compile the compiler (because compilers like to take compile-time configuration). Moreover, you're going to have to have specific code for handling every different compiler with all its quirks, you're also going to have to spend a lot of time figuring out all the quirks. And you're going to have to spend a lot of time duplicating the code which implements those quirks. Surely getting compilers to support some standard hermetic building facilities would be easier and better in the long run than maintaining a complex database of compiler quirks to handle for every specific compiler version etc? > Hermetic builds won't ever be perfect, but you can make it 80% of the way with only a few things. Yes but I can already get it 80% of the way with redo. > Surely redo can as well, but as I've thought about how to do that, it seems awkward. Perhaps you can prove me wrong? I'm still not sure we're both on the same page for what a "dynamic dependency" is but with redo I've solved the problem of having a dynamic .do file by simply depending on a dynamically generated .rc file: i.e a file containing sourcable shell variables (including bash arrays), generated using declare -p or things like the @Q parameter transformation. >Finicky because as far as I can tell, the build database in redo is modified by multiple commands over a build. This can cause problems should a problem occur with the database mid-build. In a self-contained system, the database is in-memory during the entire build and only written out to disk once the build is done, which can then be used as a sort of "commit" of the build, marking it as finished. There are no concurrency issues with the build database in any redo implementation worth it's salt and realistically there's nothing stopping a redo implementation from implementing its database the way you describe. It's also an implementation detail which I've never had to interact with. Not sure how that makes it finnicky. > I think a good paper to read would be the Dolstra thesis on Nix. [3] If you consider Nix a build system (not just a package manager), it goes further than even Bazel. The thesis should be a good place to start. From what I've seen, nix is too coarse grained for being a build system, which is where I've seen bezel recommended, but both of these fail to provide a general purpose build system which can be used outside a tightly controlled environment to build a piece of software hermetically using existing system dependencies. At the end of the day, I want to be able to build software with existing system dependencies provided by my package manager with the assurance that if I hit build, if those system dependencies have changed, the relevant parts of my code will be forced to rebuild and I will be told about it. I can see the value of totally hermetic builds, but a build system capable of solving the problem I describe should easily be extendable to solve the general problem of hermetic builds. In short, I want to be able to compile my code with my existing compiler, and if my compiler is updated, I want to be able to hit redo and have everything rebuilt correctly without worrying that something didn't get built.

ghoward 5y ago
At this point, it seems to me like you have already decided I am wrong, no matter what I say, and have no desire to accept what I say that is meant to help you. So I'll just leave the conversation where it is. I will say, though, that if you're not hearing about my build system in a few years, you can safely assume that you were right and that I was wrong.
- Arch-TK 5y ago
  > At this point, it seems to me like you have already decided I am wrong, no matter what I say, and have no desire to accept what I say that is meant to help you. So I'll just leave the conversation where it is. It seems a bit defeatist to say this. Nobody on the internet, or the world for that matter, (unless they're agreeable and are just pretending to agree with you) is going to agree with you after the exchange of a few messages. I should point out that I never disagreed with your fundamental claim that it would be easier to make a hermetic build system IF it's all encompassing and complicated. It's for example why systemd is easier to write if it's all tightly coupled versus if it was trying to have minimal coupling with minimal simple APIs and minimal simple tools building it up. It's easier to write complex and tightly coupled software, it's why everyone does it instead of following the unix philosophy. I was simply pointing out that the unix philosophy was successful (for a while) for a reason, not because it was easy to follow it, but because the difficulty of making things simple paid off in the long run. Please read what I wrote, I never made any hard claims about you being wrong, I've been mostly asking questions to get you to elaborate your stance. The sheer fact that I'm willing to entertain such long-form conversation should be enough proof of the fact that I haven't completely mentally dismissed your arguments as outright wrong. > I will say, though, that if you're not hearing about my build system in a few years, you can safely assume that you were right and that I was wrong. I don't think popularity (which is what you appear to be aiming for) is a good metric of the quality of software. Especially in the modern day and age where one of the most popular methods of shipping cross platform software is to ship it with its own instance of chromium and to write it as a local webapp. I think this is at least because modern day humans have become a lot more impatient and a lot more focused on short term convenience over long term benefits. But this discussion is outside of the scope.

ghoward 5y ago

At this point, it seems to me like you have already decided I am wrong, no matter what I say, and have no desire to accept what I say that is meant to help you. So I'll just leave the conversation where it is. I will say, though, that if you're not hearing about my build system in a few years, you can safely assume that you were right and that I was wrong.

Arch-TK 5y ago
> At this point, it seems to me like you have already decided I am wrong, no matter what I say, and have no desire to accept what I say that is meant to help you. So I'll just leave the conversation where it is. It seems a bit defeatist to say this. Nobody on the internet, or the world for that matter, (unless they're agreeable and are just pretending to agree with you) is going to agree with you after the exchange of a few messages. I should point out that I never disagreed with your fundamental claim that it would be easier to make a hermetic build system IF it's all encompassing and complicated. It's for example why systemd is easier to write if it's all tightly coupled versus if it was trying to have minimal coupling with minimal simple APIs and minimal simple tools building it up. It's easier to write complex and tightly coupled software, it's why everyone does it instead of following the unix philosophy. I was simply pointing out that the unix philosophy was successful (for a while) for a reason, not because it was easy to follow it, but because the difficulty of making things simple paid off in the long run. Please read what I wrote, I never made any hard claims about you being wrong, I've been mostly asking questions to get you to elaborate your stance. The sheer fact that I'm willing to entertain such long-form conversation should be enough proof of the fact that I haven't completely mentally dismissed your arguments as outright wrong. > I will say, though, that if you're not hearing about my build system in a few years, you can safely assume that you were right and that I was wrong. I don't think popularity (which is what you appear to be aiming for) is a good metric of the quality of software. Especially in the modern day and age where one of the most popular methods of shipping cross platform software is to ship it with its own instance of chromium and to write it as a local webapp. I think this is at least because modern day humans have become a lot more impatient and a lot more focused on short term convenience over long term benefits. But this discussion is outside of the scope.