Mac Support

[luciusDXL]

The Force Engine should compile and run on recent OS X platforms, including M1 Macs.

[gilmorem560]

In addition to the changes needed for #89, I'm finding that clang++ on macOS Monterey at least does not appear to be happy with in-place object instantiation/anonymous initialization. I by no means consider myself a C++ savant, so I'm not sure what the proper term for that is in this language, but for instance on line 173 of TFE_Asset/vueAsset.cpp:

transforms.push_back({ rotScale, translation });

fails in clang++, but:

VueTransform transform = { rotScale, translation };

transforms.push_back(transform);

works.

That aside, stepping through the basics of a macOS build, I'll mention any particular gotchas here, then resolve the necessary changes between this and #89, then expect another PR with the code changes relevant to a functional build on both. That said, I'll make note that I may require someone else to run through building a Windows copy with those changes to ensure there are no regressions before merge, I don't have a Windows machine I could use for that currently.

[sofakng]

Is this still on the roadmap or being developed?

[gilmorem560]

I haven't touched anything personally in a while. There was some debate over the use of XDG variables in the past (not POSIX, don't apply to macOS) but most other stuff done for the Linux support, at least that I contributed to, should be POSIX and therefore constitute mac support as well.

I seem to recall all of one time actually getting the OpenGL surface to pop up, but it was so long ago now, I don't know if that has since been paved over.

All that to say, I suspect that it shouldn't be hard to get this over the finish line for macOS, but I'm not actively making any contributions at this point and couldn't tell you who is paying attention to portability concerns.

If anyone does want to take a concerted swing at it I'm happy to help out.

P.S. A bridge to this working may be experimenting with the codebase using XQuartz. That'll get you running on macOS without needing as much of the underlying toolkit stuff to be perfectly Cocoa-ready.

[dgorshkov]

(this is an upvote)

[sofakng]

I would also really like to see macOS support...

[gilmorem560]

At the time (two years ago) the work as I saw it entailed taking the Linux build at the time, trying to build it on Mac, and squashing compiler bugs as they arose. I don't know what state the Linux build is in today, but so long as Linux support bits are built in a POSIX-y way, the only Mac-specific bits would be Cocoa-related methinks, and imGUI may abstract most if not all of that away. Well that and the object instantiation mentioned above, clang doesn't like it.

If that eases anyone's trepidation at taking a swing, that's what I would do if I had bandwidth to start studying this again, I don't remember running into a question I couldn't answer through available documentation back when I got an OpenGL surface to pop up on my Mac properly. Good luck!

[mikesk8]

Is there still a chance the Mac version happens soon? ;-)

[Burrito78]

Just leaving a comment as my vote for a macOS build. Thank you.

[jodaco]

Tried to build on an M1 Mac and thought I would note a few issues here, unclear if some of these are clang related or MacOS's STL at this time:

• sprintf is currently deprecated on MacOS, get warnings about it
• QUAD_MAX is defined in limits.h
• clang doesn't like while (buf[i++] = readNumber(&ptr));, it wants parentheses around the assignment inside the while loop's parantheses
• clang also does not seem like switch statements that don't have a default case handler, in case of the KEYWORD enum being handled, it complains of not every enum value being handled.
• Some calls to TFE_System::logWrite pass a std::string through a variadic function, which is not allowed.
• Conversions from size_t * (unsigned long *) fail to the various int types in the memory handler

There are perhaps more issues, but this is what I had time to collect today.

[mlauss2]

Tried to build on an M1 Mac and thought I would note a few issues here, unclear if some of these are clang related or MacOS's STL at this time:

* [ ]  sprintf is currently deprecated on MacOS, get warnings about it

* [ ]  QUAD_MAX is defined in limits.h

Are these 2 apple specific things? I don't see sprintf() being deprecated in any official standards document, and QUAD_MAX isn't predefined on linux/windows either. But the change is simple enough.

* [ ]  clang doesn't like while (buf[i++] = readNumber(&ptr));, it wants parentheses around the assignment inside the while loop's parantheses

* [ ]  clang also does not seem like switch statements that don't have a default case handler, in case of the KEYWORD enum being handled, it complains of not every enum value being handled.

Yeah clang-only warnings,

* [ ]  Conversions from size_t * (unsigned long *) fail to the various int types in the memory handler

Don't see those with clang on linux, can you please post the error messages?