At work, now I can reply more effectively here.
Please make a debug build -DCMAKE_BUILD_TYPE=Debug and post the log and a screenshot of the contents of the selected root.
I think that on OS X CMake automatically generates multiple build configurations including Debug and Release so specifying CMAKE_BUILD_TYPE should not be necessary rather specifying -configuration Debug when running xcodebuild from the command line.
Correct, I don't need to rerun CMake to generate a debug build so I'll be building one shortly.
I'm not sure that using prebuilt wxWidgets libs will work. I don't know how portable wx-config is. wx-config is the command line tool generated as part of the wxWidgets build process that tells CMake where to find the headers/libraries and probably also something about what compiler/linker flags to use. EDIT: I'm also not wild about a set of libs that was built using custom patches; those patches will need to be stored somewhere so that we can rebuild the libraries as we surely would need to do at some point -- and would the patches necessarily work at that point?
I assumed that portability was the point of wx-config. All it would need to do is be in the same relative place to the rest of the files and it could figure things out from there I would imagine. Easy enough for me to test though, I'll just move my folder to somewhere else and see if it still compiles, links, and runs successfully. If that works it should work on any other machine.
I guess that people/CMake could download the SDL2.framework from its official source and put it in ~/Library/Frameworks. If done automatically by CMake it would need to be done before trying to detect SDL2 of course. Since FSO uses a pre-bundled build of SDl2.framework though I don't see why wxL couldn't as well. At least that way we have a version of SDL2 that we know will work.
Right now, I believe FS2's setup checks for a system lib first and downloads to a local cache, and uses that, if none is found. It keeps that library location within the build folder so as not to make any external changes. Ripping that behavior out I hope would not be too difficult if it seems like a good practice to follow. But allowing users to have a globally or user installed copy already would be fine, I just don't know if ~/Library/Frameworks is normally considered a searched location or not, so there may not be any general purpose reason for placing it there?
Yes, building wxL from scratch is a bit of a pain; however, it isn't particularly difficult and the new instructions are pretty detailed as to what to do. It's not much more than installing a few things and copy/pasting some commands. I'm not convinced that homebrew makes things any easier than just following the wxL ReadMe, especially if custom patches are required for Homebrew (none are required for the wxL ReadMe approach) and as mentioned above I'm not sure that using prebuilt wxWidgets libraries will work.
It's not too difficult now but we have already established mechanisms in place in FS2 that could make it even less difficult and more approachable, not to mention simply quicker to get off the ground. If the wheel is already invented I don't see a good reason not to use it.
I don't know why Python 2 now works all of a sudden. I guess I can take a look at it again. My python skills are limited/rusty and I don't think I could update the scripts to work with both 2 and 3.
As IssMneur already mentioned, the lines that were breaking python 2 were removed (at different times oddly but both finally got pulled out. It was the 'from builtins import *' lines in a couple of files. With those gone, no need to install anything but pip and a couple of modules.
FWIW the way I build wxWidgets uses wxOSX (Cocoa) rather than wxMac (Carbon IIRC). It's what's detected by default by configure and I think is the more modern wx port for OS X.
The build I made labeled itself as a 'cocoa' build, and I believe the wxmac in homebrew is a 'cocoa' build as well. I haven't seen a Carbon anything in a long time.
wxL releases for OS X have always been Unicode.
Interesting, I thought that at least in 2.8 they had a regular and a Unicode version but I may be confusing it with another project.
Admittedly, with the way I build wxL, for some reason the wxlauncher top menubar now appears to be empty. Personally I do not feel this is worth trying to fix. wxL can be shut down either from clicking on the red X button in the corner or by quitting from the Dock. EDIT 2: That does also mean no About menu option however that wasn't cross-platform anyway and you can still get the version by right clicking on the .app and selecting Get Info.
Yes, I saw the same behavior. At one point previously, I had the menu bar, and I believe I had built against wxmac from Homebrew when I had it. But now it is gone for me as well. The way I usually quit apps though is Cmd+Q, and that doesn't work, which is kind of irritating. But hitting the red button will have to work unless we can figure that out.
Also, repeating what I said before:
Also, just my opinion, but I don't think we should officially support OS X build setups that don't follow the instructions in the OS X section of the wxL ReadMe, which rules out things like Homebrew. By follow the instructions I mean using Python 3, latest stable wxWidgets 3.x, SDL2.framework from FSO source tree, building wxWidgets manually using specific configure flags, and calling CMake with the specified flags. It should be possible to configure the CI server such it follows the instructions in the ReadMe. It's hard enough getting wxWidgets/wxL/SDL2 to work together on a known setup like using wxWidgets built with very specific parameters (see the wxL ReadMe's revised OS X section) and the SDL2.framework from the FSO source tree. However, I guess supporting multiple versions of wxWidgets and Python is reasonable, although I couldn't get the build system to work with Python 2, so I gave up and used 3 instead.
Definitely, homebrew isn't require now as far as I'm concerned. I'd rather that the CI stuff even stop using it in favor of something like I've suggested that would download the necessary libs when necessary or keeping them in the repository. I don't know if brew is available in the CI environment or not, but if it's not, we could stop having to add it via the CI script as well which could possibly simplify things more. Having the CI and the end user using the same files and commands for building would mean a much more reliable CI confirmation. Other than that, I agree with at the moment following the instructions closely is the easiest way to get a successful build. I just think we could eliminate some steps for the developer/user. Python 2 works now so we can avoid needing to install python 3. If python 2 is still what comes with 10.12, I don't see a reason to require every mac user to install python 3 when they all have 2 available. If it comes with python 3 now we may want to consider making that the officially supported one, but writing python 2/3 compatible code is not terribly hard these days, if using a new enough python 3. The SDL2 framework does not need to come from FSO, it is the official framework file there, so we can just tell people to get the latest official SDL2 framework (or specify 2.0.4 if we want to ensure parity). People may already have it installed in a global location so telling them they have to get the FSO one is not necessary. We do need to fix a bug where if you _do_ have it installed via Homebrew, it won't find it in the ~/Library/Frameworks location and will link against the wrong one.
Using a wxWidgets that is precompiled but providing the compiling instructions for users who want to do it themselves should be fine. These aren't patches I found on a random forum thread, they are the ones used by homebrew for their own release to fix compilation issues. I'm actually not sure how you were able to compile it without any patches as I ran into issues that were resolved specifically by one patch in that patch set. The other two patches sounded useful enough so I included those as well. Some were already applied upstream by wxWidgets, they just wouldn't make it to an official release tree unless they release another 3.0.x build.
Ultimately, I agree, we should be able to support both a precompiled wxWidgets or a wxWidgets build following a narrow set of instructions, one or maybe both python versions, and only the SDL2 framework file. If someone wants to try to maintain wx 2.8 support that's fine too I guess, but I think we'd be better moving forward to 3.1.x support than backwards to a deprecated version.