Hi, >> You're right. Path with colons just work in GNU Makefiles. > > Okay, after a few seconds of head-scratching - you mean they _don't_ work... Sorry! You're of course right. I wanted to write _don't_ work... >> You're right. But unfortunately this makes things in this scenario >> even worse. cc65 isn't a Cygwin program and therefore writes "native" >> Windows paths into the .d files. > > Hm, I have no Windows around (are you running Windows there?) to check that but quoting Uz from his last message: > > "[...] when checking for a path separator, the software checks for '/' or '\', and it uses '/' when inserting one." > > Still - this might be only when he specifically needs to deal with constructing the paths himself With "native" Windows path is wasn't refering to '\' (which in most cases can easily replaced with '/'). Rather I was refering to the '<driveletter>:' prefix. >> Just avoiding that very small overhead for sure wouldn't have made Uz >> change the code. Rather it was the option to avoid the weird hacks >> necessary today on Windows / Cygwin. > > Does this mean that the "previous" --create-dep, which was in fact taking the system includes into account was actually giving those headaches? Yes! I wasn't diving into a discussion of those issues in "our" recent Makefile threads as they wouldn't have made any difference... But here very briefly: - You need to set CC65_HOME to /dir1/dir2/ _without_ a <driveletter>: prefix. Obviously this means you need to run make from the same drive. - For Cygwin you need to additionally mount <driveletter>:\dir1 as /dir1. Then both the compiler and make agree on the path /dir1/dir2/ Ugly (tm), isn't it? Regards, Oliver ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sun May 2 23:11:07 2010
This archive was generated by hypermail 2.1.8 : 2010-05-02 23:11:10 CEST