[jg18]

That dialog only appeared in this new release I built.  Wasn't in the last official mac builds.  So maybe it auto generated since I used a newer wxwidgets library, I don't know.

Hmm, interesting. The last official wxL release for OS X used wxWidgets 2.8.12.

Later today I can try using wxWidgets 3.1.0 and seeing if I also get this new top menu with the About dialog. If so, maybe I should use 3.1.0 with the official OS X builds instead of 3.0.2. My original reasoning was to go with latest stable version, although I think the official Windows builds of 0.12.0-rc2 use wx 3.1.0.

EDIT: Added quote for clarity.

[chief1983]

That build used 3.0.2 from home brew FYI.  But I did remove both of the python "builtin imports" lines, if the python code has anything to do with it.

[jg18]

I don't think the Python scripts are involved with the OS X top bar menu, and even if they somehow are, removing the builtins lines shouldn't have an effect. I assume you did that for Python 2 compatibility?

Are you using the SDL_fix patch I posted on the previous page of this thread? If not, best guess is that repeatedly re-initializing and shutting down SDL video or perhaps not initializing SDL video at wxL startup causes the menu to not appear? But I'm really not sure. And if you are using the patch, then I have no idea.

In other news, wxL on Linux with the SDL patch segfaults on wxL startup. Don't you just love cross-platform?

Looks like we'll have to maintain the current setup for Linux with the custom main function. Having more platform-specific code for both Linux and OS X is but I think we're stuck with it.

Updated patch that has been tested on OS X and Linux:

http://joshuaglatt.com/SDL_fix.new.patch

Also pasting it here as a permanent copy:

Code: [Select]

:
diff --git a/code/apis/JoystickManager.cpp b/code/apis/JoystickManager.cpp
index c15c097..f357809 100644
--- a/code/apis/JoystickManager.cpp
+++ b/code/apis/JoystickManager.cpp
@@ -164,7 +164,10 @@ bool JoyMan::Initialize(ApiType apiType) {
 #if HAS_SDL
  if (currentApi == API_SDL)
  {
- SDL_InitSubSystem(SDL_INIT_JOYSTICK | SDL_INIT_HAPTIC);
+ if (SDL_InitSubSystem(SDL_INIT_JOYSTICK | SDL_INIT_HAPTIC) < 0) {
+ wxLogError(wxT_2("SDL Joystick failed to initialize."));
+ return false;
+ }
 
  JoyMan::clearSDLJoystickList();
 
diff --git a/code/tabs/BasicSettingsPage.cpp b/code/tabs/BasicSettingsPage.cpp
index f1947b6..4de6493 100644
--- a/code/tabs/BasicSettingsPage.cpp
+++ b/code/tabs/BasicSettingsPage.cpp
@@ -1600,6 +1600,12 @@ void BasicSettingsPage::FillResolutionDropBox(wxChoice *resChoice,
  // FSO currently only supports the primary display
  const int DISPLAY_INDEX = 0;
 
+#if IS_APPLE // can't initialize SDL video on startup on OS X so must do it when needed
+ if (SDL_InitSubSystem(SDL_INIT_VIDEO) < 0) {
+ wxLogFatalError(wxT_2("SDL video subsystem failed to initialize!"));
+ }
+#endif
+
  if (SDL_GetNumVideoDisplays() > 0) {
  int numDisplayModes = SDL_GetNumDisplayModes(DISPLAY_INDEX);
 
@@ -1618,6 +1624,9 @@ void BasicSettingsPage::FillResolutionDropBox(wxChoice *resChoice,
  } else {
  wxLogWarning(_T("SDL reported no displays!"));
  }
+#if IS_APPLE
+ SDL_QuitSubSystem(SDL_INIT_VIDEO);
+#endif
 #else
 #error "BasicSettingsPage::FillResolutionDropBox not implemented because not on windows and SDL is not implemented"
 #endif
diff --git a/code/wxLauncherApp.cpp b/code/wxLauncherApp.cpp
index 34e83be..9f21b95 100644
--- a/code/wxLauncherApp.cpp
+++ b/code/wxLauncherApp.cpp
@@ -47,11 +47,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
 
 #include "global/MemoryDebugging.h" // Last include for memory debugging
 
-#ifndef WIN32
-// main needs to be handled by us as SDL interferes with wxWidgets
+#if IS_LINUX
+// main needs to be handled by us on non-Mac *nix as SDL interferes with wxWidgets
 IMPLEMENT_APP_NO_MAIN(wxLauncher);
 #else
 // Windows is fine and also needs special WinMain treatment
+// OS X can't have SDL2 and wxWidgets 3 both initializing at startup
 IMPLEMENT_APP(wxLauncher);
 #endif
 
@@ -283,8 +284,8 @@ int wxLauncher::OnExit() {
  HelpManager::DeInitialize();
  SkinSystem::DeInitialize();
 
-#if HAS_SDL == 1
- SDL_Quit();
+#if IS_LINUX && HAS_SDL == 1
+ SDL_QuitSubSystem(SDL_INIT_VIDEO);
 #endif
 
  }
@@ -294,11 +295,11 @@ int wxLauncher::OnExit() {
  return wxApp::OnExit();
 }
 
-#ifndef WIN32
+#if IS_LINUX
 int main(int argc, char** argv)
 {
 #if HAS_SDL == 1
- if (SDL_Init(SDL_INIT_VIDEO) < 0)
+ if (SDL_InitSubSystem(SDL_INIT_VIDEO) < 0)
  {
  wxLogFatalError(wxT_2("SDL_Init failed"));
  return 1;

Iss Mneur, can you try this patch on Windows?

[chief1983]

That was without the patch, haven't had a chance to test it yet.

[Iss Mneur]

@jg18 the patch doesn't cause any crashes on Windows, though it doesn't seem to actually be initialized because the preprocessor blocks.

I made changes in this pull request for it to be initialized on windows and it doesn't seem to cause any crashes (though the resolutions are now duplicated, which I will be fixing).

[Iss Mneur]

I have revised the pull request (several times) to fix the resolution box.  Assuming the CI build passes and it can be confirmed that the pull request will run on OSX and Linux I will make 0.12.0-rc.3 official and if there are no further breaking bugs I will publish 0.12.0 on the main thread about 1 week after that.

0.12.0 will not include the removal of the help or the addition of the about button because 0.12.0 fixes a lot of things that are not in the official release.

[jg18]

CMake is failing when I try to use it on the fix/osxsdl branch of your (Iss Mneur) fork, even after I apply my WIP (needs cleanup) patch to get CMakeLists.txt to work on OS X.

Is that branch up to date with the master branch of the scp-fs2open repo?

CMake output:

Code: [Select]

$ /Applications/CMake.app/Contents/bin/cmake -G Xcode -DwxWidgets_CONFIG_EXECUTABLE=/Users//Downloads/wxWidgets-3.0.2/build-debug/wx-config -DPYTHON_EXECUTABLE=/usr/local/bin/python3 -DCMAKE_OSX_DEPLOYMENT_TARGET=10.7 -DCMAKE_C_COMPILER_ID=Clang -DCMAKE_CXX_COMPILER_ID=Clang -DCMAKE_CXX_FLAGS="-stdlib=libc++ -std=c++11" -DCMAKE_EXE_LINKER_FLAGS=-stdlib=libc++ ../
-- The CXX compiler identification is Clang
-- The C compiler identification is Clang
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
CMake Error at 3rdparty/GetVersionFromGitTag.cmake:63 (list):
  list index: 1 out of range (-1, 0)
Call Stack (most recent call first):
  CMakeLists.txt:21 (include)


CMake Error at 3rdparty/GetVersionFromGitTag.cmake:65 (list):
  list index: 2 out of range (-1, 0)
Call Stack (most recent call first):
  CMakeLists.txt:21 (include)


--- Configuring wxLauncher release-0.9.5+210.c9f20be
-- Searching for wxWidgets
-- Found wxWidgets: -L/Users//Downloads/wxWidgets-3.0.2/build-debug/lib;;;-framework IOKit;-framework Carbon;-framework Cocoa;-framework AudioToolbox;-framework System;-framework OpenGL;/Users//Downloads/wxWidgets-3.0.2/build-debug/lib/libwx_baseu_net-3.0.a;/Users//Downloads/wxWidgets-3.0.2/build-debug/lib/libwx_osx_cocoau_qa-3.0.a;/Users//Downloads/wxWidgets-3.0.2/build-debug/lib/libwx_osx_cocoau_richtext-3.0.a;/Users//Downloads/wxWidgets-3.0.2/build-debug/lib/libwx_osx_cocoau_html-3.0.a;/Users//Downloads/wxWidgets-3.0.2/build-debug/lib/libwx_osx_cocoau_adv-3.0.a;/Users//Downloads/wxWidgets-3.0.2/build-debug/lib/libwx_osx_cocoau_core-3.0.a;/Users//Downloads/wxWidgets-3.0.2/build-debug/lib/libwx_baseu_xml-3.0.a;/Users//Downloads/wxWidgets-3.0.2/build-debug/lib/libwx_baseu-3.0.a;-framework WebKit;-lexpat;-lwxregexu-3.0;-lwxtiff-3.0;-lwxjpeg-3.0;-lwxpng-3.0;-lz;-lpthread;-liconv;-llzma (found suitable version "3.0.2", minimum required is "2.8.10")
-- Found OpenAL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenAL.framework 
-- Configuring incomplete, errors occurred!

I’m confused by the line

Code: [Select]

--- Configuring wxLauncher release-0.9.5+210.c9f20be


Besides that, I don’t think 0.12.0-rc3 is ready even after the SDL stuff is done. As noted above, we still need to get committed  my fix to get CMakeLists.txt working on OS X again. (Or is that fix only needed before the 0.12.0 final release?)

On top of that, there’s the patch in this post to fix some crashes I was getting on OS X on wxL exit, as well as the patch in this post to fix the copyright symbol that appears when you Get Info on the wxlauncher.app on OS X.

The ReadMe also needs to be updated with new build instructions for OS X but that can wait until after the rc3 release.

[Iss Mneur]

@jg18: fetch from the issmneur repository again, it seems that I hadn't pushed tags to my personal clone in several years.  Normally I just add my personal repo as a new remote so I get all of the tags from the main repository.

I’m confused by the line

Code: [Select]

--- Configuring wxLauncher release-0.9.5+210.c9f20be


The versioning code uses the tags in the repository to make the version numbers put into the filenames (unfortunately it can't do the ones embedded in the binary yet, primarily because it doesn't update like it is supposed to).

Besides that, I don’t think 0.12.0-rc3 is ready even after the SDL stuff is done. As noted above, we still need to get committed  my fix to get CMakeLists.txt working on OS X again. (Or is that fix only needed before the 0.12.0 final release?)

I was not aware there were more changes for CMakesLists.txt that had not been presented as it has been building fine on the CI server.  So, yes I would like as much of the fixes to be in rc3 as possible, if only because 0.12.0 has not been tested on OS X because a binary version has not yet been made available.

On top of that, there’s the patch in this post to fix some crashes I was getting on OS X on wxL exit, as well as the patch in this post to fix the copyright symbol that appears when you Get Info on the wxlauncher.app on OS X.

The ReadMe also needs to be updated with new build instructions for OS X but that can wait until after the rc3 release.

I understood they were were no longer needed because of SDL patch, but I will add them to the pull request today.

The ReadMe needs some updating for Windows as well.

EDIT: The Copyright symbol is fine on my machine and is being rendered correctly on github

[Iss Mneur]

Patches have been updated on the fix/osxsdl.  Note I did rebase that branch on the updated master.

[jg18]

PR branch with SDL fix seems to work on OS X and Linux, although I’m not sure how to make a release build on Linux with cmake/make. At least I think a debug build is built by default?

However:

- Still occasionally getting the resolution box populated twice on OS X, making the list of resolutions duplicated. can’t reproduce on Debug build, and doesn’t happen consistently on Release or RelWithDebInfo builds. I wonder if it’s a race condition somewhere. Trying to debug but Xcode isn’t my strongest skill (why does it keep displaying assembly instead of C++ code? ) so it may be hard for me to debug. Maybe I can see if I can reproduce it on Windows and then use Visual Studio to debug.

- The PR’s patch to fix the TCManager crash was applied to the TCManager constructor and not the TCManager destructor where the crash was occurring. This needs to be corrected.

- The patch to fix the copyright symbol on OS X (see my previous post for the link to the post containing the patch) didn’t get added to the PR.

- New crash on wxL exit on OS X. Looks like sometimes the Logger is destroyed before the StatusBar is, resulting in a crash in the StatusBar destructor, since dynamic_cast<Logger*>(wxLog::GetActiveTarget()) returns nullptr.

Quick fix:

Code: [Select]

diff --git a/code/controls/StatusBar.cpp b/code/controls/StatusBar.cpp
index 3fd4585..82188c3 100644
--- a/code/controls/StatusBar.cpp
+++ b/code/controls/StatusBar.cpp
@@ -77,7 +77,11 @@ StatusBar::StatusBar(wxWindow *parent)
 }
 
 StatusBar::~StatusBar() {
- dynamic_cast<Logger*>(wxLog::GetActiveTarget())->SetStatusBarTarget(NULL);
+ // logger could be null if Logger already destroyed, so must check
+ Logger* logger = dynamic_cast<Logger*>(wxLog::GetActiveTarget());
+ if (logger) {
+ logger->SetStatusBarTarget(NULL);
+ }
 }
 
 void StatusBar::OnSize(wxSizeEvent& WXUNUSED(event)) {


[jg18]

Ok, here's a patch to update CMakeLists.txt and the ReadMe.md for current versions of OS X/Xcode/SDL2/wxW3.

http://joshuaglatt.com/wxLOSXupdate.patch

EDIT: Not yet working. It's linking against the sDL2.framework in my ~/Library/Frameworks/ folder instead of the copy inside the wxL app bundle. Looking into it.

[jg18]

Still working on getting wxL to link against the SDL2 private framework inside its app bundle and not the specific framework CMake finds in ~/Library/Frameworks. I wonder how I got this working with SDL before the switch to SDL2.


However:

Issue with duplicate resolution list tracked down.

It's the line

Code: [Select]

this->SetUpResolution();
that was added to BasicSettingsPage::OnFlagFileProcessingStatusChanged() which eventually occurs when an EVT_TC_BINARY_CHANGED event is generated, such as when the player changes the selected FSO build.

This issue doesn't happen with the OpenAL combo boxes because BasicSettingsPage::SetupOpenALSection() initializes OPenAL only if the playback device combo box is empty.

Similarly, this issue doesn't happen with joysticks (just tested it with my CH Pro Throttle) because the joystickSelected combo box is cleared at the top of BasicSettingsPage::SetupJoystickSection().

Probably the best solution is to clear the resolution list box in BasicSettingsPage::SetUpResolutions(). It makes sense to do so since we might be switching between SDL2 and WIn32 for resolution detection.

I get that resolution and joystick lists need to be redetected in case we switch between SDL2 and Win32, but why also OpenAL? The OpenAL stuff shouldn't need to be redetected except I guess on OS X where there are FSO builds using APple's OpenAL and (eventually) builds using OpenAL Soft. Not worth worrying about at the moment I'd say, it's likely still a ways off before we have widely used OpenAL Soft builds on OS X.


To refresh you rmemory, here's the complete function from BasicSettingsPage.cpp:

Code: [Select]

void BasicSettingsPage::OnFlagFileProcessingStatusChanged(wxCommandEvent& event) {
const FlagListManager::FlagFileProcessingStatus status =
static_cast<FlagListManager::FlagFileProcessingStatus>(event.GetInt());

if (status == FlagListManager::FLAG_FILE_PROCESSING_OK) {
this->SetupOpenALSection();
this->SetupJoystickSection();
this->SetUpResolution();
}
}

Also, here's a patch to clear the resolution combo box before setting up resolutions:

http://joshuaglatt.com/refreshRes.patch

[Iss Mneur]

Probably the best solution is to clear the resolution list box in BasicSettingsPage::SetUpResolutions(). It makes sense to do so since we might be switching between SDL2 and WIn32 for resolution detection.

Okay.  But the resolution box should be cleared by whoever causes the binary to change.  Centralizing the solution is fine though.

I get that resolution and joystick lists need to be redetected in case we switch between SDL2 and Win32, but why also OpenAL? The OpenAL stuff shouldn't need to be redetected except I guess on OS X where there are FSO builds using APple's OpenAL and (eventually) builds using OpenAL Soft. Not worth worrying about at the moment I'd say, it's likely still a ways off before we have widely used OpenAL Soft builds on OS X.

Because this might be the first time the selected binary is valid.  This event happens whenever the binary is changed regardless of why.

[chief1983]

Still working on getting wxL to link against the SDL2 private framework inside its app bundle and not the specific framework CMake finds in ~/Library/Frameworks. I wonder how I got this working with SDL before the switch to SDL2.

This has recently been fixed in the FS2 repository.  You can see one of the recent commits to the platform-darwin.cmake file.  Besides that, just have to ensure that a post-build instruction is added to the xcode project to ensure the SDL2 Framework ends up in the app bundle.

The reason that commit works that way, is that the SDL2 framework is looked for by the binary in a location relative to @loader_path, and that is set in the SDL2 libary's @rpath variable.  It is different from the other Frameworks FS2 links against, but it works now, and it's how it was done pre-CMake as well.

[jg18]

Yup those extra lines added to CMakeLists.txt fix things. Now the SDL2.framework inside the app bundle is being used. Thanks, chief!

Updated patch for CMakeLists.txt and ReadMe.md, with target updated to 10.9 instead of 10.7:

http://joshuaglatt.com/wxLOSXupdate.patch

Now, if we get all of these patches added to the wxL PR, I think we're good to go!

Namely:


- Update CMakeLists.txt and ReadMe.md for OS X:
http://joshuaglatt.com/wxLOSXupdate.patch


- Clear the Resolution combo box when detecting resolutions
http://joshuaglatt.com/refreshRes.patch


- Fix the copyright symbol on the OS X app bundle
http://joshuaglatt.com/wxLfixCopyright.patch


- Ffix the crash in the StatusBar destructor
http://joshuaglatt.com/wxLfixStatusBar.patch


- Correct the TCManager fix to use it in the TCManager destructor rather
than the constructor, although having it there too doesn't hurt
http://joshuaglatt.com/wxLfixTCManager.patch
EDIT: Actually if the ProfileManager isn't initialized by the time the TCManager is constructed, that's a problem, since then the TCManager can't register itself as an event handler with the ProfileMnanager. I guess we could have a wxASSERT(ProManWhatever IsInitialized()) in the TCManager constructor.

[Iss Mneur]

Code has been committed and pull request has been merged.  It appears that the changes have broken the CI's ability to find SDL on OS X, see this log.

[jg18]

Code has been committed and pull request has been merged.  It appears that the changes have broken the CI's ability to find SDL on OS X, see this log.

Looking at the log, I can't find anything indicating that detecting SDL2 failed, could you quote the relevant lines for that?

The only failure I see unfortunately has no details as to what exactly failed. Looks like FileProfileManager.cpp failed to compile and it doesn't say exactly what line(s) failed. AFAIK that file doesn't use SDL2.

Code: [Select]

** BUILD FAILED **

The following build commands failed:

CompileC travis-build/wxlauncher.build/Debug/wxlauncher.build/Objects-normal/x86_64/FileProfileManager.o code/apis/FileProfileManager.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler

(1 failure)


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.

I'm also concerned about these lines from the log:

Code: [Select]

Warning: You are using macOS 10.9.

We (and Apple) do not provide support for this old version.

You may encounter build failures or other breakages.


EDIT: Yes I know the wxL ReadMe currently says you can use Homebrew. I think we should drop support for that and support exactly one build setup for OS X.

[Iss Mneur]

Code has been committed and pull request has been merged.  It appears that the changes have broken the CI's ability to find SDL on OS X, see this log.

Looking at the log, I can't find anything indicating that detecting SDL2 failed, could you quote the relevant lines for that?

Code: [Select]

CMake Warning:
  Manually-specified variables were not used by the project:
    USING_SDL_FRAMEWORK


The only failure I see unfortunately has no details as to what exactly failed. Looks like FileProfileManager.cpp failed to compile and it doesn't say exactly what line(s) failed. AFAIK that file doesn't use SDL2.

Code: [Select]

** BUILD FAILED **

The following build commands failed:

CompileC travis-build/wxlauncher.build/Debug/wxlauncher.build/Objects-normal/x86_64/FileProfileManager.o code/apis/FileProfileManager.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler

(1 failure)


For some reason the rest of the message is printed later

Code: [Select]

▸ Compiling FileProfileManager.cpp
❌  /Users/travis/build/scp-fs2open/wxLauncher/code/apis/FileProfileManager.cpp:33:10: 'SDL_filesystem.h' file not found
#include <SDL_filesystem.h>
         ^


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.

That is fair.  The primary reason that we support multiple python and wxWidgets versions if for the Linux people that are expected to build from source.

The only reason that Windows supports multiple versions of python and wxWidgets is so that I (as a Windows user) can debug them when they fail on linux.  The official windows builds are all built with one version of python, wxWidgets, and Visual Studio.

If you want to take a stab at fixing it by making it follow the readme then make a pull request, it will build them automatically.  Don't worry about appveyor, I have another pull request in process to get that to work.

I'm also concerned about these lines from the log:

Code: [Select]

Warning: You are using macOS 10.9.

We (and Apple) do not provide support for this old version.

You may encounter build failures or other breakages.


EDIT: Yes I know the wxL ReadMe currently says you can use Homebrew. I think we should drop support for that and support exactly one build setup for OS X.

Yeah, that seems to be new.  I assume it is from brew and is because Apple released 10.12 on Tuesday.

[Iss Mneur]

I'm also concerned about these lines from the log:

Code: [Select]

Warning: You are using macOS 10.9.

We (and Apple) do not provide support for this old version.

You may encounter build failures or other breakages.


EDIT: Yes I know the wxL ReadMe currently says you can use Homebrew. I think we should drop support for that and support exactly one build setup for OS X.

Yeah, that seems to be new.  I assume it is from brew and is because Apple released 10.12 on Tuesday.

Seems it is a brew problem.  It is supposedly fixed, but I changed the OS X image that we are using to match what you wrote the readme against and now it is gone.  Replaced by a bunch more warning and still the failure with FileProfileManager.cpp

The only failure I see unfortunately has no details as to what exactly failed. Looks like FileProfileManager.cpp failed to compile and it doesn't say exactly what line(s) failed. AFAIK that file doesn't use SDL2.

Code: [Select]

** BUILD FAILED **

The following build commands failed:

CompileC travis-build/wxlauncher.build/Debug/wxlauncher.build/Objects-normal/x86_64/FileProfileManager.o code/apis/FileProfileManager.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler

(1 failure)


For some reason the rest of the message is printed later

Code: [Select]

▸ Compiling FileProfileManager.cpp
❌  /Users/travis/build/scp-fs2open/wxLauncher/code/apis/FileProfileManager.cpp:33:10: 'SDL_filesystem.h' file not found
#include <SDL_filesystem.h>
         ^
Seems that this include is for SDL_GetPrefPath which is new in SDL 2.0.1 !?

[jg18]

Finally got a chance to reply, been busy all day.

BTW, does the CI system stop compilation as soon as it encounters an error? I don't understand why it didn't try to compile the other wxL source files.


Also I noticed that the GitHub online version of ReadMe.md leaves out anything I put in angle brackets so I'll need to fix that. Maybe I can wrap variables in the ReadMe in curly braces instead? Will need to check if that's compatible with GitHub's markdown, for example, that /Users/{YourUsername}/Library/Frameworks/ will appear with the curly braces intact. Originally I used angle brackets but apparently those don't work.

Code: [Select]

CMake Warning:
  Manually-specified variables were not used by the project:
    USING_SDL_FRAMEWORK


If CMake couldn't find SDL2, there would be a fatal error message "SDL2 not found". The USING_SDL_FRAMEWORK (I thought I changed it to say SDL2?) was to allow Homebrew users to use their own version of SDL2 instead of FSO's SDL2.framework. As mentioned I think we should stop officially supporting Homebrew for building wxL. I can revise  a ReadMe.md to say that at the same time that I resolve the issue with the angle brackets (see above).

For some reason the rest of the message is printed later

Code: [Select]

▸ Compiling FileProfileManager.cpp
❌  /Users/travis/build/scp-fs2open/wxLauncher/code/apis/FileProfileManager.cpp:33:10: 'SDL_filesystem.h' file not found
#include <SDL_filesystem.h>
         ^


As mentioned CMake found SDL2. The problem is that CMakeLists.txt assumes you're using SDL2.framework and hardcodes the SDL2 include path to be to the detected SDL2 library's Headers subfolder, since for any framework the Headers subfolder is the include path.

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.

That is fair.  The primary reason that we support multiple python and wxWidgets versions if for the Linux people that are expected to build from source.

Glad you agree.

If you want to take a stab at fixing it by making it follow the readme then make a pull request, it will build them automatically.  Don't worry about appveyor, I have another pull request in process to get that to work.

I'm not sure what that pull request would look like. Can you explain how to do it? Following the wxl ReadMe instructions for OS X shouldn't require more than general basic Unix command line skills. The only tricky part is that to copy a framework using cp you need to use the -R option to copy the entire framework folder.

Seems it is a brew problem.  It is supposedly fixed, but I changed the OS X image that we are using to match what you wrote the readme against and now it is gone.  Replaced by a bunch more warning and still the failure with FileProfileManager.cpp

Could you quote the section with the extra warnings? It's easier than me trying to find it when I'm not familiar with how the log normally looks.

Code: [Select]

▸ Compiling FileProfileManager.cpp
❌  /Users/travis/build/scp-fs2open/wxLauncher/code/apis/FileProfileManager.cpp:33:10: 'SDL_filesystem.h' file not found
#include <SDL_filesystem.h>
         ^
Seems that this include is for SDL_GetPrefPath which is new in SDL 2.0.1 !?

Not sure the version number is significant if the issue is that the compiler just can't find the include folder. As mentioned above CMakeLists.txt now hardcodes the include path to be ${SDL2_FRAMEWORK}/Headers.


Ideally if we're going to require using SDL2.framework to build wxL on OS X, CMakeLists.txt should check if SDL2_FRAMEWORK (what find_library() finds) actually is a framework and print a fatal error if it is not. Not sure how to do that with CMake or if it's even possible. Basically just means checking that the library found ends in ".framework".