181–190 of 257 posts
Earlier quoted context omitted.
I think he was referring to the Intro page [1][2]. [1] http://sinatrarb.com/intro.html [2] https://github.com/sinatra/sinatra#readme
I was referring to the landing page: http://sinatrarb.com/
Earlier quoted context omitted.
Good to know that you live in a privileged place and access a fast internet connection. Most of the places don't have that kind of bandwidth [1] to download 600 MB of file in 40 seconds. Also, Bazel needs a huge amount of RAM because of JVM and runs a daemon process in the background to speed up the build duration. Running a background JVM daemon process is a NO for me and Bazel wastes system resources. [1] https://e…
> Most of the place don't have that kind bandwidth… Most people don’t have the kind of bandwidth it takes to download a 50 MB binary? Are we still talking about Bazel here, because that’s the size of the download. What about tools like compilers? You have to download those, too. > Running a background JVM daemon process is a NO for me and Bazel wastes system resources. What system resources does it actually use up? A…
I don't install tons of random garbage because I want to know and understand what is running on the hosts that I maintain.
I need to be able to debug the stuff I run, and complexity makes it difficult.
Tenths of MB of stuff is complexity. Tenths of build time or run time dependencies is complexity. A compiled tool when a script would have been sufficient is also complexity.
Earlier quoted context omitted.
Make has a laundry list of problems: - Cannot handle multiple outputs for a single rule - Does not rebuild when flags change - Make rules may contain implicit dependencies - Slow for large codebases - Does not understand how to build for multiple platforms, sucks for cross-compiling - Recursive make sucks (job control does not work across recursive invocation boundaries) - You must create output directories yourself…
Make does support multiple outputs, though the syntax sucks. Most of what you are annoyed with though is like being annoyed at C for the same reasons: Make is a programming language with a built-in dependency mechanism, and as such you can use it to build whatever you want... now, does it already come with whatever you want? No. I can appreciate wanting something which does. But such systems usually then give you wha…
No, it doesn’t. There’s NO syntax for multiple outputs. If you can show me what the syntax is and prove me wrong, I’d love to see it. At best, there are workarounds for the lack of multiple output support, with various tradeoffs.
> Make is a programming language with a built-in dependency mechanism, and as such you can use it to build whatever you want...
Make is NOT a programming language. End of story. You can… kind of… build things with it, given that variables in Make can be used like functions, but it’s goddamn horrible and you shouldn’t do it because nobody will want to use it and nobody will maintain it.
At most, you can build something on top of Make, but you’re still facing the limitations of Make and working around them. If you are interested in building something on top of a low-level build system, you want Ninja instead of Make, because Ninja is good at that. Make isn’t.
Make is, at best, something you would want to use for a small C program where all the files are in one directory. Once you grow past that use case, my rule is that you shouldn't be using Make any more, because there are just too many things that Make does wrong.
Make is successful because eh, it’s good enough for small things, you can suffer through the pain if you need to use it for big things, and it was the first tool to solve this problem. We have better tools now. We had better have better tools now! Make is in its fifth decade… if we didn’t improve on Make in that many years, that would be a damning indictment of the entire field.
Hey guys! Thanks for checking Please out! I see a lot of recurring themes in the comments so I thought I would clear some things up. What is Please? Please is a multi-language build system designed for huge mono-repos. It was created by a couple frustrated ex-googlers who were familiar with Blaze (which was later open sourced as Bazel). We found the "real world" alternatives to be somewhat lacking and so Please was b…
Earlier quoted context omitted.
Bazel doesn’t need the JVM as it’s built into its self contained binary.
Hm, I guess my point was that it still needs the JVM, it just uses the bundled version. I guess that wasn’t clear.
Earlier quoted context omitted.
> Most of the place don't have that kind bandwidth… Most people don’t have the kind of bandwidth it takes to download a 50 MB binary? Are we still talking about Bazel here, because that’s the size of the download. What about tools like compilers? You have to download those, too. > Running a background JVM daemon process is a NO for me and Bazel wastes system resources. What system resources does it actually use up? A…
> You are spending your precious time and energy worrying about a resource whose marginal cost to you is about the same as a cup of coffee. I don't install tons of random garbage because I want to know and understand what is running on the hosts that I maintain. I need to be able to debug the stuff I run, and complexity makes it difficult. Tenths of MB of stuff is complexity. Tenths of build time or run time dependen…
Bazel is way easier to debug than Make. Debugging a decent-sized build system made with Make is just an exercise in suffering.
I am… honestly… no longer interested in understanding the entire software stack. I understand my time on this earth is limited and want to spend it doing other things. With Bazel, I am spending less time fucking around with build systems and more time doing the stuff I care about.
> Tenths of MB of stuff is complexity. Tenths of build time or run time dependencies is complexity. A compiled tool when a script would have been sufficient is also complexity.
As someone who still writes C, I can understand the joy that people feel when you make some cool program and it’s measured in KB, not MB. However, what you’re describing strikes me as fetishistic.
Earlier quoted context omitted.
And I would have considered that to be large 20 years ago, because it would have filled an entire CD-ROM disc, and it would have taken over five hours to download. However, I still have somewhere over 100 GB free on my seven-year-old laptop, and the download will take me ~40 seconds. But even if the 600MB were a problem, Bazel doesn’t need an external version of the JVM. It bundles its own, and fits the whole thing i…
50mb for a build tool is still ludicrous. Very few product codebases will ever reach that size. In my experience there is a strong correlation between executable size and how hard it is to unravel any issue that arises in it.
Bazel bundles the JRE, that’s why it’s 45 MB.
The correlation is kinda beside the point, though, because my experience with Bazel is that it’s easier to unravel issues with Bazel than unravel issues with Make, and Make is much smaller.
First thing every software engineer does after leaving Google is rewrite Blaze. Just like every site reliability engineer rewrites borgmon. What I chose to do myself was make Blaze happen using a Makefile config. There's a blog post somewhere where Google talks about why they switched from GNU Make to Blaze c. 2006. if I remember correctly it basically boiled down to not having strict dependency checking. So I though…
Reading your words, it looks like you have made a kind of make replacement that just works. Following your link, it looks like... what ? I don't know, some tool that checks some build configuration, augments C and postprocesses executable files? (Looking at https://github.com/jart/cosmopolitan it's an interesting hack. Might be useful in some cases, for example command-line tools like git.) Have you made something th…
You love to see it.
Earlier quoted context omitted.
Make has a laundry list of problems: - Cannot handle multiple outputs for a single rule - Does not rebuild when flags change - Make rules may contain implicit dependencies - Slow for large codebases - Does not understand how to build for multiple platforms, sucks for cross-compiling - Recursive make sucks (job control does not work across recursive invocation boundaries) - You must create output directories yourself…
I am interested in setting up cross compiling environment with Bazel. Do you have any recommended documentation that I can read?