Disclaimer: given that I am still sick (although feeling slightly better), the people I met through uh social networking apps earlier this week and tried to meet IRL all flaked on me
I'm typing this in Notepad++ which has ****ty accessibility, and that now I have to fix the aforementioned wxL bug on Linux (the platform where my assistive technology skills are the least developed), I'm not really in the cheeriest of moods. That said....
No argument there, and having a system that can automatically retrieve and utilize the necessary dependencies the same way for both release builds, dev builds, and CI builds would greatly increase the effectiveness of the CI system overall.
As would having a system that builds stock wxWidgets without modifications using a single standardized set of configuration commands, meaning among other things no support for libraries built with additional patches or with Homebrew.
Removing Python 3 I agree with, but in the OS X specific section we may want to clarify again that there are some required Python modules that don't ship with OS X. Guessing that's already in the README but at least mentioning to re-read that part might be helpful then.
The only required python module that's not in the standard distribution is markdown and yes the OS X section of the ReadMe will mention that, as it currently does and always has.
Not sure about that. Could build it every time at least I guess, only an extra few minutes right?
If the libraries are being used on the same machine over and over there's no reason to build them more than once. But yes you're right they could be rebuilt every time.
I built release builds as I believe that's what we've been using all along for prebuilt libs for FSO. We aren't debugging the libs themselves I think, so I don't believe we need the added debug bulk.
I like to use debug builds of wxWidgets with debug build releases of wxL. wxWidgets can act strangely (e.g., wxWidgets assertions mysteriously triggered, yes this has happened) and having those debug symbols can be helpful. I do use release builds of wxWidgets with official release builds of wxL though.
There's also the chance that for whatever reason, other users might run into difficulties compiling the libraries themselves and get frustrated before they even get to trying to compile our code. Now, there's no one saying you should _have_ to use our libs, as the mechanism to override the lib location would always remain.
If someone is following the wxL ReadMe but unable to build the libraries, then something is wrong with the ReadMe and it needs to be updated. Building wxL should always work if the ReadMe is followed to the letter. Yes that was impossible to do with the old set of ReadMe instructions; this should be fixed with the updated instructions. I will update the ReadMe to clarify that even though I specify the exact versions of software I used, the user may have success with earlier or later versions (e.g., Xcode 8.0 rather than 7.3.1). And as I have said more than once with Iss Mneur's support, I do not want to have to support multiple ways to build wxL.
Regex replacement was one such possible solution the problem, it's definitely not the only one. Using a temp directory that is always the same would work just as well, and /tmp/ I think would be a good candidate for that. I have the libs currently set up to install to /tmp/wxmac/ so that no further changes are required to anything. I just configure wxLauncher to find the library there and it works. The lib could be stored on bintray if not in the repository, downloaded, extracted to /tmp/, and then nothing else would need to be done. And this would only be done if wxWidgets were not detected during the configuration in an existing location. This a mechanism already established and tested in the current FSO CMake files. Nothing groundbreaking here, we just would need to apply established concepts to this project from FSO.
This is admittedly a more palatable approach than regex hacking, but what if the path the prebuilt libraries use is taken? Unlikely but a possibility we have to account for.
I'm honestly not sure how you were able to compile stock wxWidgets 3.0.2 without error on Mac, when both myself and the people apparently maintaining the wxmac build in Homebrew all ran into the same compilation error. I am on 10.11 until my new work Macbook comes in and I can upgrade this one, and I was on Xcode 7.3.x at the time, now I'm on Xcode 8. I could try again with the new SDK to see if the patches are still necessary. That said, if a dedicated maintainer also feels those patches add value to the wxWidgets source base when compiled on OS X, it seems like a useful thing to consider using ourselves. It would actually make the library closer to the Homebrew wxmac release as well.
As I have said multiple times, I have no interest in supporting Homebrew, and furthermore I see no value in getting a set of libraries that's closer to the Homebrew version. Is the Homebrew version officially sanctioned by the wxWidgets team? If it is, then perhaps I stand corrected.
Please try building the wxWidgets 3.0.2 official release using the instructions in the wxL ReadMe and report back with your results. I used the Clang compiler that ships with Xcode 7.3.1 on 10.11 but can't imagine there being an issue with using the Clang compiler that ships with Xcode 8. The configuration command in the ReadMe specifies Clang as the compiler because we need both C++11 and 10.9 support. I'm sure you know this and I'll add it to the ReadMe, but you can use the -j option with the make command to speed up the compilation process.
Also I am double especially not enthusiastic about libraries that were not only not built from an official wxWidgets release but that also include patches that are not strictly required for it to compile. It's unnecessarily veering even further away from an official release.
It is a better choice then, I agree. Downloading it automatically if it isn't found, like the prebuilt lib, could save people from even having to read the readme though, which is always nice, but at this point I wouldn't push for this too hard as it isn't hard to download a lib and put it in a user folder yourself 
I have little sympathy for people who want to build wxL but can't be bothered to even look at the ReadMe. It's called a "ReadMe" for a reason.
If I'm reading what you wrote above correctly, are we in agreement then that anyone who is unable or unwilling to download and copy a framework to ~/Library/Frameworks should not be considered able to build (let alone work on) wxL?
Is there a way to detect which is did find and issue a warning during the configuration process? It might save people the trouble from making a build, giving it out on the forums, and then getting a bunch of reports that it doesn't work. I imagine that the framework copy step would not even work correctly though, so I'm guessing something would blow up at some point if the framework isn't available. This is more just to help avoid confusion for any devs down the line as it doesn't improve the current process as long as you understand the caveats already. Not as important as fixing CI and getting a new release out the door anyway.
Yes CMake can check if the detected SDL2 library's name ends in "framework". The CMakeLists.txt revisions I'm working on do just this, with a fatal error issued if the library is not a framework. I do not want to support builds of wxL that do not use SDL2.framework. As I've said a few times in this thread and Iss Mneur has agreed with, I don't want to support multiple build setups, most notably mixing Homebrew into the build process. Using an SDL2.framework is the only supported way to build wxL. anyone who wants to use Homebrew to build any part of wxL or any dependency for it is on their own as far as I'm concerned. I see no value in supporting Homebrew.
There haven't _been_ many builds of wxLauncher, and one reason I'm guessing is that it's been such a bear to get it compiled on OS X. It sounds like you're describing a catch-22. No one has built wxL on Mac because it's difficult to build because no one has built it on Mac because it's difficult to build...
You'll have to ask Iss Mneur for why there have been few releases of wxL. Another possibility is that there hasn't been a need for frequent releases. I still don't understand how OS X taking some work to build figures in. Yes it really was a pain before the wxL ReadMe instructions were revised. Hence the new instructions that I worked very hard on getting right. I don't want to support versions of wxWidgets that were built in some other way.
Also, it's arguably even harder to build wxL on Windows, where Python isn't even included and prebuilt libraries aren't even possible because of CRT/SxS issues. And yet there actually
have been contributors on Windows such as m!m and AdmiralRalwood.
I'm just suggesting that maybe it doesn't have to be that way. I don't see how I'm suggesting a large investment as my suggestions already mirror completed tasks in FSO. Yes we either need someone to understand them and implement them here, or ask m|m to help us out since he did most of those, etc, but again, no one is talking about reinventing the wheel. If it was easier to compile, we could spend more time actually developing it, and less time trying to get it to compile for the next release. It helps that the process is better documented in the readme now though.
OS X support for wxL has fallen to me because no one else wants to do it. If someone else would like to provide OS X wxL support they can support any number of build setups they like using any sets of instructions they like. But I want one and only one way to build wxL if I'm the one doing this, and having the option to use prebuilt libraries, especially ones that were not built using official wxWidgets releases, unnecessarily makes this task even harder. As I said earlier, it's hard enough getting wxL to work with exactly one setup of wxWidgets/SDL2/etc. I do not want to have to provide support for multiple build setups.
With the new build instructions that took a lot of research and experimentation to get right (particularly with respect to configuring wxWidgets) it should no longer be particularly difficult to build wxL on OS X.
Also I have never heard an OS X user express interest in working on wxL, let alone be deterred because of the build instructions. The only other SCP C++ coders I know with a Mac are Swifty and Echelon9. To the best of my knowledge, neither one has ever contributed to wxL nor has either one expressed interest in doing so, and I am not sold on their being suddenly interested if they weren't required to build wxWidgets to work on wxL.
EDIT: Slight correction.
