World: r4wp

TO_OSXI and TO_OSX

Oh, thanks.

sys-system.h is unused, and only there to cause confusion :)

:)

The multitude of defines for platforms in the same "major" group 
is a bit of an annoyance as well.

hmm, so we'd need a disjunction

Yes, exactly.

TO_OSX || TO_OSXI

Is TO_OSX for all OSX or just PPC?

that's what this comment indicates

src/include/reb-config.h:#ifdef TO_OSXI					// OSX/Intel
src/include/reb-config.h:#ifdef TO_OSX					// OSX/PPC

TO_OSX is osx-ppc, TO_OSXI is osx-intel

OK. Good to know.

And we have no common defines for "all of ..." at the moment, unfortunately.

My only Mac is a G5.

Hmm

-#ifdef __APPLE__
+#if defined(TO_OSX) || defined(TO_OSXI)

neither are defined (unless I screwed that up!)

The only references I see in the codebase are the above ifdefs (reb-config.h)

Should be defined and passed along in your makefile.

$ grep -R TO_OSX *
src/include/reb-config.h:#ifdef TO_OSXI					// OSX/Intel
src/include/reb-config.h:#ifdef TO_OSX					// OSX/PPC

in a make/makefile for osx-intel:
TO_OS?= TO_OSXI
...
RFLAGS= -c -D$(TO_OS) -DREB_API  $(RAPI_FLAGS) $I
HFLAGS= -c -D$(TO_OS) -DREB_CORE $(HOST_FLAGS) $I

hmm

oh, mine reads TO_LINUX

shouldn't make prep have set that correctly?

make make OS_ID=0.2.5

Is there a reason that this isn't autodetected?

No good reason. But that's just how the build currently works.

Okay, thanks for the tip.

To support building Rebol for old crappy platforms with stupid make.

At least that's the stated reason. There is likely a better approach.

https://github.com/0branch/r3/commits/browse-macosx

http://issue.cc/r3/1991- BROWSE none

https://github.com/0branch/r3/commit/8eea3cf8217bd8f05ea5190fa81f5e8d8ed41cad

MarcS, with mainline R3 browse doesn't currently work on OSX, right?

Right

Unless, I guess, you have XQuartz installed with xdg-open or x-www-browse

http://issue.cc/r3/1992- BROWSE doesn't work on OSX

Great.

So should I submit pull requests referencing these tickets?

Squash the two 1992-related commits into one, and also mention the 
CureCode ticket in the commit message (something like "This fixes 
CureCode issue #1992.") and submit a pull for that.

To squash I need to rebase locally then repush?

Yes, exactly (push --force).

Okay

For #1991 se need a better approach. We aren't at the point where 
we would need to disable a feature while we wait to figure it out, 
at least for something you have to explicitly call.

Hope you don't mind the cosmetics :)

Andreas: np, just testing the squashed changeset

For #1991, we should at least get the crash removed right away.

Sufficient detail, https://github.com/rebol/r3/pull/101?

Looks good.