chuggafan

Well, it seems the analyzer was happy with your suggestion, so my original theory is correct. I'm running into other analyzer situations, but not the one I originally wanted to...

Figured out why we aren't including: We don't do in-current-directory checking for the existence of the file, unlike in the compiler.... Wonders, may try to figure out how to modify...

Upon further inspection: I have absolutely no idea how I'd accomplish this without very large rewrites and structural code changes, the main thing that I think prevents me from theoretically...

Looking at this again, I think it's possible to fix this if we change it so that the preferred path of searching for new dependencies is the same path as...

Yhea the entire reason I made this issue was because this wasn't happening, my original plan was to change the cwd to whatever the file we're working on's directory is...

Okay so this is actually more difficult than I stated it to be, I actually made an OS::GetFileDirectory function and added Shlwapi.lib for OMAKE only (yay!) and then got slapped...

Doing the investigation it seems that pathext2.mak was a separate goal from the makefile itself... my whole issue is that I have absolutely no idea how to determine the "controlling"...

Got a bit further on this by deciding that the "Source target" is the first goal in the path, however this generates the abomination of: "C:\OrangeCtreetop.mak" And of course: ```...

The question is: will we have GCC compat for certain error names? And if so, what errors are they?

Doing this while doing #610 because they're related and I think I'll use the same strategies to accomplish it. Just adding 4 macros to errorlist.h and just making it so...