The Build is Always Broken
gbracha.blogspot.com
The Build is Always Broken
1–10 of 75 posts
Re: The Build is Always Broken
#2This is what Bazel, Pants, etc (and I'm sure a bunch of other build tools) do for you. You define a dependency graph, then per commit you can see what targets have been modified and then you can run commands on only targets dependent on the modified ones.
I'm not sure why this blog post is written like these things don't exist.
EDIT: on a re read, I'm a bit off the mark. The author seems to want the compiler or interpreter that reads the code to automatically process the dependency graph of what changed (at the finest grain possible) and take appropriate action.
The company I work at has tools for automatically updating our dependency graph relationships, and then commits/diffs execute commands against the dependencies of modified targets as part of the code review and CD process. This is pretty close to what the author is suggesting.
I still think this blog post is written a bit too dramatically.
Re: The Build is Always Broken
#3Sounds like Nix to me.
Re: The Build is Always Broken
#4Is rebuilding everything from scratch on every build actually that common? If use use docker’s —cache-from flag on build, then assuming you’ve already pushed an image if you don’t make any changes on the part of the code that image is for you’re not going to actually rebuild that. That part of your build is just docker pull, build using cache, no changes so no work.
Re: The Build is Always Broken
#5Is rebuilding everything from scratch on every build actually that common? If use use docker’s —cache-from flag on build, then assuming you’ve already pushed an image if you don’t make any changes on the part of the code that image is for you’re not going to actually rebuild that. That part of your build is just docker pull, build using cache, no changes so no work.
Incremental compilation isn’t the only point of the article
Re: The Build is Always Broken
#6gcc can generate make dependencies since forever ago. That with ccache and distcc enables an environment where most of the time, compiling just a file or two plus linking needs to be done. For C at least, this problem has been solved for a while.
Re: The Build is Always Broken
#7gcc can generate make dependencies since forever ago. That with ccache and distcc enables an environment where most of the time, compiling just a file or two plus linking needs to be done. For C at least, this problem has been solved for a while.
Not really.
Indeed, the building blocks for fast iteration are there, but as always in the 40-years-old ecosystem of C, no coherent solution has emerged and dominated the landscape.
Re: The Build is Always Broken
#8This is one area where Electron really shines. For example, VS Code is a reasonably large project, yet one can make a modification and play with it within a couple seconds (~200ms to recompile the changes, a second or two to reload the window). I’d be curious if anyone here knows how InteliJ or Eclipse compares?
Re: The Build is Always Broken
#9I'm used to using a Continuous Integration (CI) system which doesn't allow code to be merged unless it builds and tests pass. This does not allow for super fast merging as builds take time and testing takes time. But it prevents builds from breaking.
The system I have been using is: https://zuul-ci.org/
Not exactly what the main focus of the article. But when the article talks about "the build is broken" then using a CI system which prevents that is good. It doesn't prevent an individual developer from breaking their local build of course.
Re: The Build is Always Broken
#10This is one area where Electron really shines. For example, VS Code is a reasonably large project, yet one can make a modification and play with it within a couple seconds (~200ms to recompile the changes, a second or two to reload the window). I’d be curious if anyone here knows how InteliJ or Eclipse compares?
Aren't there native GUI toolkits for JavaScript too though?