Re: [cc65] Relative paths during compilation

From: <silverdr1wfmh.org.pl>
Date: 2010-05-02 20:36:25
On 2010-05-02, at 20:21, Ullrich von Bassewitz wrote:

>> Maybe a stupid question but don't you have to process the different path
>> styles in various places already? Don't you have any #ifdefs related to the
>> target host platform?
> 
> No, there are no target host specific defines. There are a few places where
> measures are taken to cope with different compilers, but not with target
> operating systems. But that doesn't mean that the sources will compile on
> absolutely arbitrary systems. It is assumed that '/' or '\' is a path
> separator, and it is assumed that the operating system is able to understand
> '/' as a path separator. Or in other words, when checking for a path
> separator, the software checks for '/' or '\', and it uses '/' when inserting
> one. This works for all major operating systems(*) and even a few not-so-major
> ones:-)
> 
>> If not at all then it would really be a pity to lose
>> this "cleanness" but (without checking the sources) I somehow doubt it.
> 
> I think I mentioned more than one time that I don't like #ifdefs, so I've
> tried hard to avoid them. Which - in case of a compiler or other command line
> tools - is not too hard. So you must not doubt any longer, just believe it:-)

I surely believe you! I also loathe the #ifdefs, and OTOH admire highly that there is e.g. no need for any configuration required to build current cc65 on various platforms. But these are often two things: "not liking" or "trying hard to avoid" this approach, and being able to get fully rid of them. SInce you managed that - in such case it would indeed be a wrong way to (re-)introduce such stuff. No further questions on that.

With best regards,

-- 
SD!----------------------------------------------------------------------
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 20:36:30 2010

This archive was generated by hypermail 2.1.8 : 2010-05-02 20:36:33 CEST