Often this is because some part of either the IDE or the build chain failed to clear some part that needed to be cleared. Especially for large projects and on older machines, compiling takes a while. Usually only small changes are made during programming, so to optimize the work flow it tries to only re-compile what absolutely needs to be recompiled. This speeds up the process, allowing for iterative development without waiting a long time.
I remember working with Java on my old Pentium 1 system and it taking easily 45 mins to compile something. That’s where the xkcd 303 got its origins. xkcd.com/303/
But sometimes this fails in some way, which can lead to very bizarre results. Often causing headscratches figuring out what went wrong, assuming the fault to be in what the developer did. A quick way to check is to simply delete the intermediate compiler result (often the obj or bin dir, or both) and do a whole fresh compile. Sometimes it’s enough to simply compile again, often when the error was caused by some race condition in the build process. For example something being flagged as needing cleanup, but the build being done before the cleanup was done. A recompile at that point will probably work as the cleanup has most likely happened.
Sometimes shit’s just cursed and there is no explanation, probably angered some coding god somewhere. Perform the proper ritual and you’re good to go.
LovableSidekick@lemmy.world 1 week ago
This phenomenon was around eons before LLMs. You have to figure out how conditions are different when the problem happens in the wild and when you fail to duplicate it.
boonhet@sopuli.xyz 1 week ago
I was mostly kidding. You can always run into weird caching issues and I’m sure there are other issues I haven’t thought of.
Docker builds in particular feel like a double edged sword. On the one hand, the entire team has the same build environment regardless of their machines. On the other hand, if docker’s cached old versions of packages in a preliminary step (e.g sudo apt-get install whatever) and something has a bug, you might run into issues till you clear the cache and rebuild then.
LovableSidekick@lemmy.world 1 week ago
Tbh I’ve never used Docker, but the idea that it’s a perfect bulletproof solution to environmental issues has always seemed overly rosy to me.
boonhet@sopuli.xyz 1 week ago
It’s very far from a bulletproof solution and it can cause its own issues, but if used properly, there are a lot of issues that it can help prevent.
Put it this way: Production is on the Eclipse Temurin flavour of JDK, but your new developer downloads the Oracle one off java.com instead. Ideally both should function the same, they implement the same Java spec after all! But there might be a bug in one or the other that changes how something works.
Now you could just provision machines with a particular environment setup, and not let your developers install random-ass packages, but most smaller companies I’ve worked for don’t really practice that for developers (less technical employees are another story). You get full admin access to your machine and you can customize your environment.
Instead, your new developer builds the same docker container that runs in your kubernetes cluster. Same base image, same dependencies installed, etc. Day one and the project builds fine (assuming the code itself works).
However, it’s not perfect. For one, sometimes an older version of a distro won’t support a newer version of some really low-level dependency for some weird-ass reason. It’s a fixed bug in newer versions, but your new employee decided to install Debian Stable on their machine so now they have to install docker from somewhere other than the main Debian repo. Another issue is the caching I mentioned beforehand.
If you’ve never used docker before, I’ll give you a quick rundown on how building a docker image works, just in case.
Generally you first pull from a base image. Depending on your use case, it might just be ubuntu 24.04, or maybe you take an image that already includes the toolchain you need (e.g a jdk image for java stuff). Your base image itself could also be based on another image, with extra stuff added. There could be tons of layers, the ‘base’ image is just the last layer you import from elsewhere before you start doing your own stuff. Then in the dockerfile, you can use different commands to build your own custom image, such as copying files from some directory on your system to the new image (like your code), or you can literally run bash commands as well. Say you used a Debian or Ubuntu base and you need some library from their repo, you just sudo apt-get install it. Or similarly you install your npm or pip or whatever packages before building. The thing is, and you can disable this, to save time, and bandwidth, docker will cache the results of each step and use cached versions up until the first step where it detects changes (usually to the files you copy to your image). But if you want it to be performant, you do all your dependency installs before your filesystem stuff so those steps don’t get re-run each time you change your code. So the first time you build an image on a particular computer, it pulls the dependencies and then until you do a clean build it might never pull them again. That’s where you can run into issues.
And yes, you can just include the dependencies in a base image that gets built automatically in the CI and only add the code and compile steps in the image you build on the local machine. But you still have to pull the new base image!