[Zimwy]

Hi everyone,
I was wondering if anybody knows how to detect the OS version at compile time? I want to know this specifically because between panther and tiger apple changed how appendBezierPath works. In 10.3, if you did [myPath appendBezierPath: otherPath] it would *return* the new one. Now, under Tiger, it returns void and instead does more what you'd think which is append otherPath to myPath.
Unfortunately, I need to be able to compile my program under 10.3 and 10.4, so I'm looking for a way to do something like this:
#ifdef _TIGER
[myPath appendBezierPath: otherPath];
#elif
[self setPath: [myPath appendBezierPath: otherPath]];
#endif

I'm pretty sure I can do this by just adding a -D_TIGER to my gcc flags, but I was wondering if GCC defines anything for you (for instance GCC defines __APPLE__).

Thanks!
gabe

[Wevah]

Hmm, my Panther documentation says:

- (void)appendBezierPath:(NSBezierPath *)aPath

So, if the documentation is correct, it's never returned the new path...

[Diggory Laycock]

You can either check for AppKit's version or check for the method's presence:

http://cocoadevcentral.com/articles/000067.php

http://www.cocoabuilder.com/search/a...appkit+version

[Kristoff]

uname

[Angus_D]

It never returned it, you were relying on a magic coincidence. The fact that the compiler didn't warn you was a bug.

[Zimwy]

Hey Guys,
Thanks. Haha, that's pretty funny. Yeah it was really bad about what it'd warn me about. Nothing when I'd never return anything in a function that returned. I had warnings on too. Anyway, thanks a bunch.

Gabe

[smeger]

I'd actually still like an answer to the original question, for a similar reason. There's some NSTableView stuff that's deprecated on Tiger, but the replacement doesn't exist for earlier versions.

[Chuckit]

What's wrong with checking AppKit's version, smeger? That actually sounds like a better solution than compile-time checking, because then you can dynamically use the right code for whichever version the user has.

[smeger]

Because I get compile-time warnings for using an undefined method. And I always write my code to be warning-free.

[Wevah]

respondsToSelector: ?

[smeger]

That's what I wound up doing, Wevah. But I don't like it, and I'd rather do a compile-time check.

[Wevah]

There are a bunch of defines you can check for if you want to go that route. I think using respondsToSelector: is the best way though, at least for shipping software.

[Angus_D]

Originally Posted by smeger

That's what I wound up doing, Wevah. But I don't like it, and I'd rather do a compile-time check.

So you don't want to use it even if it's available when you're running on Tiger?

Look at AvailabilityMacros.h and the following things:
http://developer.apple.com/releaseno...ityMacros.html
http://developer.apple.com/technotes/tn2002/tn2064.html

[smeger]

Okay, this whole discussion was the result of a giant brain fart on my part. Sorry for wasting everyone's time.

I was thinking about things in terms of my own test code, rather than in terms of shipping code. As I was working on Tiger compatibility for one of my apps, I often compiled it on Tiger and I often compiled it on Panther. I like to compile with zero warnings, so my "without really thinking it through" idea was to add a compile-time check and compile in only the appropriate case.

Of course, this is a totally stupid idea if I'm actually shipping an app that can run on either Tiger or Panther. So, again, my apologies for the time waste.