This was a weird one, so I’m going to write about it to show how we found the answer. Both myself and a coworker develop on macbook computers and for some bezar reason I could build the code on my machine, but the same folder of code on his machine would result in a make error aobut
No rule to make target 'x.oo', needed by 'y'. Stop. Error. We tried everything, even making sure we were both using the same version of make and that our build system was the same. Eventually, inorder to debug this both of us ran make and sent the output to a file and then diffed those two files. What we discovered we initially thought was weird but didn’t make much sense. There was the obvious, his was skipping building the object for x.oo and then complaining about it not being there for the next step. The second thing was that the apsolute paths on his machine was
/users/<username>/workspace/trunk where mine was
/Users/<username>/workspace/trunk. The important thing to note is that on his system all the abolute paths thought that the users directory is all lower case. We oppened finder and saw that on his machine users was not lower case, it was Users. The reason for this is he created an alias to cd into the source directory of our project with an absolute path in his bashrc:
alias cdsrc='cd /users/<username>/workspace/trunk/src'
He would use this to jump right to the directory. This seams to work and after he would do this the terminal would “preserve” the path that he gave it and his pwd was:
This doesn’t seam like it should be a problem except that realpath in gnu make that searches for dependencies assumes you are on a case sensitive linux filesystem. You can configure your HFS+ mac filesystem to be case sensitive which would avoid all this (stackoverflow). This was just one of those weird ones and the real lession is that make errors might seem imposible to fix but there are always clues to help you figure it out if you look closely enough in the output.