41–50 of 71 posts
Uber is migrating from Buck to Bazel, for instance.
Software development is all about not re-inventing the wheel. Yet there are countless build systems, tons of pointless frameworks. I wonder developers have nothing else to do. Every company releases their own version of everything.
My understand of Buck (and Pants) is that they are the result of ex-Google employees going to other companies (resp. Facebook, Twitter), realizing that Blaze was more or less the Right Way to do a build system (at least for their set of circumstances), and then being forced to re-implement the ideas from scratch (edit: or memory, or exfiltrated docs/code) because Blaze was not open source. Reusing extant software is…
Earlier quoted context omitted.
Can you explain why? I’d be interested to learn more.
Apart from issues pertaining timestamp granularity and clock skew, there is a problem that is technically not about timestamps but is related since it's often a consequence of the dependency data model employed by that class of build systems. Consider this makefile rule: foo.a: $(patsubst %.c,%.o,$(wildcard *.c)) Now, the foo.a target will be considered as stale if any of timestamps of it's dependencies is newer than…
The blog post [0] also contains arguments against checksums: Sometimes building a target has side effects. Checksumming every output after building it is somewhat slow. Checksumming every input file before building is very slow.
Earlier quoted context omitted.
My understand of Buck (and Pants) is that they are the result of ex-Google employees going to other companies (resp. Facebook, Twitter), realizing that Blaze was more or less the Right Way to do a build system (at least for their set of circumstances), and then being forced to re-implement the ideas from scratch (edit: or memory, or exfiltrated docs/code) because Blaze was not open source. Reusing extant software is…
“Reimplementation from scratch” seems like a generous description of Buck. It was initially so like Blaze that I always assumed a xoogler exfiltrated at least the documentation of Blaze.
Software development is all about not re-inventing the wheel. Yet there are countless build systems, tons of pointless frameworks. I wonder developers have nothing else to do. Every company releases their own version of everything.
https://en.wikipedia.org/wiki/Not_invented_here
Now they have to maintain a fork instead. What's worse is they likely wont know how it works in a year's time, imagine in a few years when they need him to update the library.
Sometimes it's better to buy a library than to waste resources reinventing someone else's tried and tested wheel.
Earlier quoted context omitted.
Apart from issues pertaining timestamp granularity and clock skew, there is a problem that is technically not about timestamps but is related since it's often a consequence of the dependency data model employed by that class of build systems. Consider this makefile rule: foo.a: $(patsubst %.c,%.o,$(wildcard *.c)) Now, the foo.a target will be considered as stale if any of timestamps of it's dependencies is newer than…
According to Apenwarr (redo implementer) claims [0] that checksums are not necessary, if you extend the mtime with size, inode number, file mode, owner uid, owner gid, and (targets only) the sequence number of the last time it was built. The blog post [0] also contains arguments against checksums: Sometimes building a target has side effects. Checksumming every output after building it is somewhat slow. Checksumming…
Earlier quoted context omitted.
Apart from issues pertaining timestamp granularity and clock skew, there is a problem that is technically not about timestamps but is related since it's often a consequence of the dependency data model employed by that class of build systems. Consider this makefile rule: foo.a: $(patsubst %.c,%.o,$(wildcard *.c)) Now, the foo.a target will be considered as stale if any of timestamps of it's dependencies is newer than…
According to Apenwarr (redo implementer) claims [0] that checksums are not necessary, if you extend the mtime with size, inode number, file mode, owner uid, owner gid, and (targets only) the sequence number of the last time it was built. The blog post [0] also contains arguments against checksums: Sometimes building a target has side effects. Checksumming every output after building it is somewhat slow. Checksumming…
What matters is keeping track of the actual dependencies and Redo does indeed save that knowledge in a database that gets consulted between runs.
Earlier quoted context omitted.
My understand of Buck (and Pants) is that they are the result of ex-Google employees going to other companies (resp. Facebook, Twitter), realizing that Blaze was more or less the Right Way to do a build system (at least for their set of circumstances), and then being forced to re-implement the ideas from scratch (edit: or memory, or exfiltrated docs/code) because Blaze was not open source. Reusing extant software is…
“Reimplementation from scratch” seems like a generous description of Buck. It was initially so like Blaze that I always assumed a xoogler exfiltrated at least the documentation of Blaze.
Software development is all about not re-inventing the wheel. Yet there are countless build systems, tons of pointless frameworks. I wonder developers have nothing else to do. Every company releases their own version of everything.
I, for one, applaud the effort. Maybe someday we can finally relegate CMake to the dustbin of history.