Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Iss Mneur on February 08, 2015, 11:53:08 pm

Title: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on February 08, 2015, 11:53:08 pm
Announcing wxLauncher Test Builds

(https://raw.githubusercontent.com/wiki/wxLauncher/wxlauncher/images/header.png)

For an explanation of what wxLauncher is, see the official release post (http://www.hard-light.net/forums/index.php?topic=67950.0).

We ask that any issues that you find with this build are posted to this thread (not the main release thread) or to the GitHub issue tracker (https://github.com/wxLauncher/wxlauncher/issues).  We are also looking for comments that it works on the various platforms that are supported.

Remember the builds posted in this thread are only minimally tested. You should back up your wxLauncher profile directory (the same place that your log file is written) if you value your settings.

Important Known Issues

Downloads (https://github.com/wxLauncher/wxlauncher/releases)
Windows users can download the installer from the releases page (https://github.com/wxLauncher/wxlauncher/releases/tag/0.12.0-rc.2) of the wxLauncher website.  Windows users can also download the source code from the releases page.

Debian Linux users can find us as freespace2-launcher-wxlauncher on Wheezy and Jesse.  Please be aware of the version that is packaged is may be different than the currently released version.

Arch Linux users can find us as wxLauncher in the AUR.  Please be aware of the version that is packaged is may be different than the currently released version.

Linux users can download a the source from the downloads page (https://github.com/wxLauncher/wxlauncher/releases/tag/0.12.0-rc.2). At this time, most Linux users must build wxLauncher from source.  The ReadMe (https://github.com/wxLauncher/wxlauncher/blob/0.12.0-rc.2/ReadMe.md) has the build instructions.  The ReadMe is also included in the source archive and will be for the version that you download.

OS X users can download a .dmg disk image from the releases page (https://github.com/wxLauncher/wxlauncher/releases/tag/0.12.0-rc.3) of the wxLauncher website.  Binary OS X builds are still being tweaked for the new wxWidgets changes. OS X users may also wish to build wxLauncher from source; the ReadMe (https://github.com/wxLauncher/wxlauncher/blob/0.12.0-rc.3/ReadMe.md) has the build instructions.  A source tarball is available from the releases page.

If you have Diaspora R1 Patch 4 and below (1.0.4 and below). Why haven't you updated it yet?  See the release thread (http://www.hard-light.net/forums/index.php?topic=81859.0) for the patches, download this .zip file (http://www.mediafire.com/?l1i1bcb6bogzlez) of updated launcher resources and unzip it into your Diaspora folder. But really you should just update Diaspora, see the release thread

Build instructions
See the read me (https://github.com/wxLauncher/wxlauncher/blob/0.12.0-rc.2/ReadMe.md) for build instructions and requirements.

Change log
0.12.0-rc.2 fixes:
0.11.0 fixes:
0.10.0 fixes:

Troubleshooting

For Windows and OS X users, if you run into problems getting wxLauncher to run, download and install the launcher built in debug mode ("Downloads", above). Post or PM the log (which is located in %AppData%\wxLauncher (Windows), ~/.wxlauncher (Linux), or ~/Library/Application Support/wxlauncher (OS X; note the space in Application Support)).

For Linux users, to build a debug version of wxLauncher, follow the build instructions as above, but when running CMake, ensure that CMAKE_BUILD_TYPE is set to Debug (cmake -DCMAKE_BUILD_TYPE=Debug).
Title: Re: wxLauncher Test Builds
Post by: AdmiralRalwood on February 08, 2015, 11:55:09 pm
Can it retrieve highlights from the new frontpage yet?
Title: Re: wxLauncher Test Builds
Post by: Iss Mneur on February 09, 2015, 07:23:59 am
No, the existing feed doesn't work any more and I have not integrated anything to use the rss version.   That will be next along with getting the retrieval out of the main thread.

Diaspora's feed should still work though.
Title: Re: wxLauncher Test Builds
Post by: kkmic on February 10, 2015, 01:56:43 am
The news feed should work now. Just open wxL.
Title: Re: wxLauncher Test Builds
Post by: BirdofPrey on February 10, 2015, 11:31:44 pm
News is working for me at least, but it's missing some items.

Here's what it shows me:

(Re)Release: Ridiculous
Volition Interview
FS2S is back
High Def Asteroids

For reference current top four are
ST:R
FS:Port
Ridiculous
kickstarter
Title: Re: wxLauncher Test Builds
Post by: kkmic on February 11, 2015, 02:27:18 am
What it shows you are the first four highlights from the homepage (http://www.hard-light.net), not from the forums (http://www.hard-light.net/forums).

They are technically two different pages and as you can see they are showing different content - I believe this is a change that was introduced with the latest version of the HLP homepage, as in the previous version, the homepage highlights were taken from the forum, and they were always the same.

"Historically", wxL retrieved the highlights by accessing the homepage, and when the highlights retrieval got fixed, it kept retrieving them from the homepage.

So, the question is: which of the highlights "sets" is more important/up to date? Obviously, wxL can only show one of them.
Title: Re: wxLauncher Test Builds
Post by: Arkblade on February 11, 2015, 04:18:27 am
"Speech" not recognized.
 i using windows 7.
Title: Re: wxLauncher Test Builds
Post by: kkmic on February 11, 2015, 05:58:10 am
"Speech" not recognized.
 i using windows 7.

Log and/or screenshot please.
Title: Re: wxLauncher Test Builds
Post by: AdmiralRalwood on February 11, 2015, 09:17:54 am
"Speech" not recognized.
 i using windows 7.
Are you using a Nightly build? It's possible that they're compiled without the flag that enables speech support...
Title: Re: wxLauncher Test Builds
Post by: Arkblade on February 11, 2015, 04:22:59 pm
"Speech" not recognized.
 i using windows 7.

Log and/or screenshot please.
screenshot is here.

log is below
-----
15042221938:INFO :wxLauncher Version 0.9.5
15042221938:INFO :Build "release-0.9.5-0-g7ee46df115" committed on (Tue Jan 27 21:29:37 2015 -0700)
15042221938:INFO :02/12/15 07:19:38
15042221938:INFO :Initializing profiles...
15042221938:INFO : My profiles file is: C:\Users\MyName\AppData\Roaming\wxlauncher\global.ini
15042221938:INFO : Found 1 profile(s).
15042221938:INFO :Initializing SkinSystem...
15042221938:INFO :Initializing HelpManager...
15042221938:INFO :Initializing FlagListManager...
15042221938:INFO :Initializing ProfileProxy...
15042221938:INFO :wxLauncher starting up.
15042221938:STSBR:Profile 'Default' saved
15042221938:STSBR:Now autosaving profiles.
15042221939:INFO :Windows reports 1 joysticks, 1 seem to be plugged in.
15042221939:STSBR:MainWindow is complete
15042221939:STSBR:Ready.
15042221939:INFO :The current game root folder is F:\Games\Volition\FreeSpace2
15042221939:INFO : Found 2 FS2 Open executables in 'F:\Games\Volition\FreeSpace2'
15042221940:INFO :Detected OpenAL version: 1.1
15042221952:INFO :saving global profile before exiting.
15042221952:INFO :Current profile Default has no unsaved changes. Exiting.
15042221952:INFO :wxLogger shutdown complete.

Log closed.
------

3.7.0 Final is same result.
and release-0.9.4 launcher can recognized "speech" normaly.

[attachment deleted by nobody]
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Iss Mneur on February 11, 2015, 08:50:31 pm
Thanks Arkblade.

Please try downloading the installer again. It appears that speech was not enabled in the published builds.

OP has been updated.
Title: Re: wxLauncher Test Builds
Post by: niffiwan on February 11, 2015, 09:27:43 pm
News is working for me at least, but it's missing some items.

Here's what it shows me:

(Re)Release: Ridiculous
Volition Interview
FS2S is back
High Def Asteroids

For reference current top four are
ST:R
FS:Port
Ridiculous
kickstarter

What it shows you are the first four highlights from the homepage (http://www.hard-light.net), not from the forums (http://www.hard-light.net/forums).

They are technically two different pages and as you can see they are showing different content - I believe this is a change that was introduced with the latest version of the HLP homepage, as in the previous version, the homepage highlights were taken from the forum, and they were always the same.

"Historically", wxL retrieved the highlights by accessing the homepage, and when the highlights retrieval got fixed, it kept retrieving them from the homepage.

So, the question is: which of the highlights "sets" is more important/up to date? Obviously, wxL can only show one of them.

 :nervous: Uh, yeah, I should get around to updating the main page highlights....  :nervous:  (aka duplicating the forum highlights)
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Arkblade on February 12, 2015, 03:52:03 am
Thanks Arkblade.

Please try downloading the installer again. It appears that speech was not enabled in the published builds.

OP has been updated.

thank you, it worked.
however it cause display disturbed.
see screenshots.


[attachment deleted by nobody]
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Iss Mneur on February 12, 2015, 07:55:58 am
Thanks Arkblade.

Please try downloading the installer again. It appears that speech was not enabled in the published builds.

OP has been updated.

thank you, it worked.
however it cause display disturbed.
see screenshots.
Hmm.  Please attach a screenshot with the voices dropdown expanded.  That drop down is way to long.
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Arkblade on February 12, 2015, 09:36:23 am
Thanks Arkblade.

Please try downloading the installer again. It appears that speech was not enabled in the published builds.

OP has been updated.

thank you, it worked.
however it cause display disturbed.
see screenshots.
Hmm.  Please attach a screenshot with the voices dropdown expanded.  That drop down is way to long.

yes, it have long strings.


[attachment deleted by nobody]
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: chief1983 on February 12, 2015, 01:05:49 pm
I don't think it's a question of 'Up to Date'.  The Home page list is the Announcements forum, the Highlights on the Forum home page is the Highlights subforum.  They're both just different forum IDs for their source.  Neither is more 'up to date' than the other, they just get different things posted.  You could merge the two...
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: AdmiralRalwood on February 12, 2015, 01:19:27 pm
I don't think it's a question of 'Up to Date'.  The Home page list is the Announcements forum, the Highlights on the Forum home page is the Highlights subforum.  They're both just different forum IDs for their source.  Neither is more 'up to date' than the other, they just get different things posted.  You could merge the two...
The old list of articles on the frontpage came from the Announcements subforum, just like the old list of highlights on the frontpage came from the Highlights subforum, but now both are separate. At the moment, the forum highlights tend to be more up-to-date than the frontpage highlights, until somebody manually updates them like so:
:nervous: Uh, yeah, I should get around to updating the main page highlights....  :nervous:  (aka duplicating the forum highlights)
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Iss Mneur on February 12, 2015, 01:34:21 pm
I suppose a better question would be, which source is more correct. According to Sandwich (http://www.hard-light.net/forums/index.php?topic=88741.msg1769711#msg1769711), at some point the existing highlights at the top of the forum pages will also come from the same source as the front page.  But that was three months ago...
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: chief1983 on February 12, 2015, 02:02:36 pm
Oh, I didn't even notice there were highlights on the front page.
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: niffiwan on February 12, 2015, 07:17:10 pm
I suppose a better question would be, which source is more correct. According to Sandwich (http://www.hard-light.net/forums/index.php?topic=88741.msg1769711#msg1769711), at some point the existing highlights at the top of the forum pages will also come from the same source as the front page.  But that was three months ago...

That's the position I've been working from, i.e. the new mainpage highlights will become the source of truth. The thing is, I'm not sure if anyone except Sandwich, Axem & myself know much about the new mainpage, whereas all the mods/admins know how to post in the highlights forum.  Probably just needs a bit of knowledge sharing, and maybe a few extra accounts setup. (And of course having the forum code changed to pull from the mainpage highlights).
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Iss Mneur on February 12, 2015, 07:43:32 pm
yes, it have long strings.
Okay.  Just to clarify this doesn't affect your ability to use speech?
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Arkblade on February 12, 2015, 11:00:41 pm
yes, it have long strings.
Okay.  Just to clarify this doesn't affect your ability to use speech?
yes, however operability will fall significantly.
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Antares on April 04, 2015, 08:00:53 am
Building under Linux Mint. 0.9.4 compiles, 0.9.5 does not.

Everything goes smoothly until I get this far:

Code: [Select]
Building CXX object CMakeFiles/wxlauncher.dir/code/apis/OpenALManager.cpp.o
/home/antares/Desktop/wxlauncher-master/code/apis/OpenALManager.cpp:28:19: fatal error: al/al.h: No such file or directory
 #include <al/al.h>
                   ^
compilation terminated.
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Iss Mneur on April 04, 2015, 09:52:03 am
please try the revision 0.9.6 branch.  It will become the next release once I get back home, only one patch is still pending
Title: Re: wxLauncher Test Builds [Updated: 2015-02-11]
Post by: Antares on April 04, 2015, 11:45:25 am
Success!
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: Iss Mneur on April 20, 2015, 08:54:14 pm
BUMP Version 0.9.6 is available for beta testing.

0.9.6 fixes:
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: niffiwan on May 02, 2015, 07:08:50 am
I've tried compiling from the revision-0.9.6 branch and I get a bunch of assertions on running wxL. It seems to at least partly work if I skip through them all, i.e. I can launch FSO.  I haven't tried changing many settings though.

Code: [Select]
../include/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
../include/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().

Here's a logfile:
http://pastebin.com/yP6Rp6qH
(yes, I have too many profiles and binaries, even after deleting all the 3.7.1 binaries)

I should also note that I've got both wxWidgets 2.8.12 & 3.0.2 installed.  2.8.12 was being selected for building even though wx-config says that 3.0.2 is the default.  I then hacked up CMakeLists.txt to make wxL use 3.0.2 but it didn't change anything.

Code: [Select]
$ git diff
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 719f70a..59a812f 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -29,7 +29,7 @@ if(NOT(DEFINED IS_WIN32 OR DEFINED IS_LINUX OR DEFINED IS_APPLE))
   endif()
 endif()
 
-find_package(wxWidgets 2.8.10
+find_package(wxWidgets 3.0.2
   COMPONENTS base core net xml html adv qa richtext)
 if(NOT wxWidgets_FOUND)
   find_package(wxWidgets 3.0.2

Lastly, I do have a single "blank" entry in my fs2_open.ini file; not sure if that's what the isEmpty() assertion is complaining about

Code: [Select]
[PXO]
FS2OpenPXO=0
Login=niffiwan
Password=redacted
SquadName=
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: Iss Mneur on May 02, 2015, 01:21:11 pm
I've tried compiling from the revision-0.9.6 branch and I get a bunch of assertions on running wxL. It seems to at least partly work if I skip through them all, i.e. I can launch FSO.  I haven't tried changing many settings though.

Code: [Select]
../include/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
../include/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
/home/mememe/src/wxlauncher/code/controls/ModList.cpp(628): assert "location.IsEmpty()" failed in readIniFileString().
Please try: https://github.com/IssMneur/wxlauncher/commit/d53dabc75bcdbe8f55115f3617fc03182eef3d61 to fix the location.IsEmpty() assertions. For the others you are going to need to start wxLauncher with gdb and have the assertion break into the debugger and generate a backtrace.


I should also note that I've got both wxWidgets 2.8.12 & 3.0.2 installed.  2.8.12 was being selected for building even though wx-config says that 3.0.2 is the default.  I then hacked up CMakeLists.txt to make wxL use 3.0.2 but it didn't change anything.

Code: [Select]
$ git diff
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 719f70a..59a812f 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -29,7 +29,7 @@ if(NOT(DEFINED IS_WIN32 OR DEFINED IS_LINUX OR DEFINED IS_APPLE))
   endif()
 endif()
 
-find_package(wxWidgets 2.8.10
+find_package(wxWidgets 3.0.2
   COMPONENTS base core net xml html adv qa richtext)
 if(NOT wxWidgets_FOUND)
   find_package(wxWidgets 3.0.2
Thanks, the issue is because GCC is more strict about formats than Visual Studio is.  What will be version 0.10 will be much better at getting the version of wxWidgets that it should.

Lastly, I do have a single "blank" entry in my fs2_open.ini file; not sure if that's what the isEmpty() assertion is complaining about

Code: [Select]
[PXO]
FS2OpenPXO=0
Login=niffiwan
Password=redacted
SquadName=
No, it is not fs2_open.ini.  Because this is from modlist, it will be something in the mod.ini's that you have.

Unrelated to the problem at hand, can you attach or put on a filehosting the od.ini from ArmorMantisMod.  It is causing some strange behaviour in your log (that seems to be only causing cosmetic issues) and I want to see what is going on.
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: Jackho on May 02, 2015, 04:09:47 pm
Yes !

I don't know what you changed in this version but you did it ! and you did well  :nod:
I can see and select my audio devices in Audio section of the Basic settings tab now. And also I don't have to copy lightning presets to custom flags to have them working in freespace. This is very good and everything is running nicely so far. I'm ready to move definitely from other launcher I used before (which is good but it's getting old and so on).

Congratulation for your work and thanks again.  :yes:

 :v-old: A+
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: niffiwan on May 03, 2015, 03:56:30 am
Please try: https://github.com/IssMneur/wxlauncher/commit/d53dabc75bcdbe8f55115f3617fc03182eef3d61 to fix the location.IsEmpty() assertions. For the others you are going to need to start wxLauncher with gdb and have the assertion break into the debugger and generate a backtrace.

Awesome, the latest IssMneur/revision-0.9.7 branch has fixed the IsEmpty asserts.  For the others, there's a snazzy window to get the backtrace from wxL itself, very nice!
Code: [Select]
ASSERT INFO:
../include/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type

BACKTRACE:
[1] wxFileConfig::Parse(wxTextBuffer const&, bool)
[2] wxFileConfig::wxFileConfig(wxInputStream&, wxMBConv const&)
[3] ModList::ParseModIni(wxString const&, wxString const&, bool)
[4] ModList::ModList(wxWindow*, wxSize&, wxString)
[5] ModsPage::OnTCChanged(wxCommandEvent&)
[6] ModsPage::ModsPage(wxWindow*)
[7] MainWindow::MainWindow()
[8] wxLauncher::OnInit()
[9] wxAppConsoleBase::CallOnInit()
[10] wxEntry(int&, wchar_t**)
[11] main
[12] __libc_start_main
[13] _start

And here's the 2nd occurrence:
Code: [Select]
ASSERT INFO:
../include/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type

BACKTRACE:
[1] wxFileConfig::Parse(wxTextBuffer const&, bool)
[2] wxFileConfig::wxFileConfig(wxInputStream&, wxMBConv const&)
[3] ModList::ParseModIni(wxString const&, wxString const&, bool)
[4] ModList::ModList(wxWindow*, wxSize&, wxString)
[5] ModsPage::OnTCChanged(wxCommandEvent&)
[6] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[7] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[8] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[9] wxEvtHandler::TryHereOnly(wxEvent&)
[10] wxEvtHandler::ProcessEventLocally(wxEvent&)
[11] wxEvtHandler::ProcessEvent(wxEvent&)
[12] wxEvtHandler::ProcessPendingEvents()
[13] wxAppConsoleBase::ProcessPendingEvents()
[14] wxApp::DoIdle()
[15] g_main_context_dispatch
[16] g_main_loop_run
[17] gtk_main
[18] wxGUIEventLoop::DoRun()
[19] wxEventLoopBase::Run()
[20] wxAppConsoleBase::MainLoop()
[21] wxLauncher::OnRun()
[22] wxEntry(int&, wchar_t**)
[23] main
[24] __libc_start_main
[25] _start

No, it is not fs2_open.ini.  Because this is from modlist, it will be something in the mod.ini's that you have.

Unrelated to the problem at hand, can you attach or put on a filehosting the od.ini from ArmorMantisMod.  It is causing some strange behaviour in your log (that seems to be only causing cosmetic issues) and I want to see what is going on.

Sure, here's the mod.ini file:
Code: [Select]
# PLEASE NOTE ALL INI SETTINGS ARE *OPTIONAL*

# modname:       Display name only, so you can have spaces instead of underscores for multi word MOD's
# image255x112:  Location of a 255x112 bmp you wish to display in the launcher
# infotext:      Text that will appear in the launcher
# website:       Link to your website
# forum:         Link to your forum
[launcher]
modname      = Armor Mantis mod;
image255x112 = ;;bplogo.bmp;
infotext     = Test how change-ship-class affects armor status. Look for the mission "Test Armor" in the tech room.
website      = ;;http://blueplanet.hard-light.net;
forum        = ;;http://www.hard-light.net/forums/index.php/board,169.0.html;
[multimod]
secondarylist = mediavps_3612;
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: Iss Mneur on May 03, 2015, 11:49:40 am
Awesome, the latest IssMneur/revision-0.9.7 branch has fixed the IsEmpty asserts.  For the others, there's a snazzy window to get the backtrace from wxL itself, very nice!
Great.  Unfortunately, with that particular assertion, the stack trace in the assert message is worthless because it doesn't have line numbers.  In ParseModIni there are three formats that it could be complaining about, and all three look fine to me.
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: niffiwan on May 05, 2015, 05:07:44 am
Ah, I should have just done what you asked to start with :)
(although, not all the frames have files/linenumbers anyway?)

1st assertion:
Code: [Select]
#0  0x00007ffff5d6fcc9 in __GI_raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff7418c78 in wxGUIAppTraits::ShowAssertDialog (this=<optimised out>, msg=...) at ../src/gtk/utilsgtk.cpp:332
#2  0x00007ffff79c065a in ShowAssertDialog (file=..., line=line@entry=451, func=..., cond=..., msgUser=..., traits=traits@entry=0x861660) at ../src/common/appbase.cpp:1302
#3  0x00007ffff79c0ced in wxAppConsoleBase::OnAssertFailure (this=this@entry=0x7f1fe0, file=<optimised out>, line=451, func=<optimised out>, cond=<optimised out>, msg=<optimised out>) at ../src/common/appbase.cpp:781
#4  0x00007ffff73f2780 in wxApp::OnAssertFailure (this=0x7f1fe0, file=<optimised out>, line=<optimised out>, func=<optimised out>, cond=<optimised out>, msg=<optimised out>) at ../src/gtk/app.cpp:507
#5  0x00007ffff79c1081 in wxDefaultAssertHandler (file=..., line=line@entry=451, func=..., cond=..., msg=...) at ../src/common/appbase.cpp:1093
#6  0x00007ffff79be06c in wxOnAssert (file=file@entry=0x7ffff7b42bae "../include/wx/strvararg.h", line=line@entry=451, func=func@entry=0x7ffff7b4de70 <_ZZN15wxArgNormalizerImEC1EmPK14wxFormatStringjE12__FUNCTION__> "wxArgNormalizer",
    cond=cond@entry=0x7ffff7b43268 "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype", msg=msg@entry=0x7ffff7b43200 "format specifier doesn't match argument type") at ../src/common/appbase.cpp:1169
#7  0x00007ffff7a1a506 in wxArgNormalizer (index=2, fmt=0x7fffffffabb0, value=10, this=<optimised out>) at ../include/wx/strvararg.h:451
#8  wxArgNormalizerWchar (index=2, fmt=0x7fffffffabb0, value=10, this=<optimised out>) at ../include/wx/strvararg.h:471
#9  Log<wxString, unsigned long> (a2=10, a1=..., f1=..., this=0x7fffffffad60) at ../include/wx/log.h:968
#10 wxFileConfig::Parse (this=this@entry=0xb514c0, buffer=..., bLocal=bLocal@entry=true) at ../src/common/fileconf.cpp:640
#11 0x00007ffff7a1e8f4 in wxFileConfig::wxFileConfig (this=0xb514c0, inStream=..., conv=...) at ../src/common/fileconf.cpp:498
#12 0x00000000004b5fc8 in ModList::ParseModIni(wxString const&, wxString const&, bool) ()
#13 0x00000000004b08c3 in ModList::ModList(wxWindow*, wxSize&, wxString) ()
#14 0x000000000049424b in ModsPage::OnTCChanged(wxCommandEvent&) ()
#15 0x0000000000493735 in ModsPage::ModsPage(wxWindow*) ()
#16 0x000000000051002c in MainWindow::MainWindow() ()
#17 0x0000000000515dba in wxLauncher::OnInit() ()
#18 0x0000000000516e45 in wxAppConsoleBase::CallOnInit() ()
#19 0x00007ffff7a4903c in wxEntry (argc=<optimised out>, argv=<optimised out>) at ../src/common/init.cpp:479
#20 0x0000000000513fa6 in main ()

2nd assertion:
Code: [Select]
#0  0x00007ffff5d6fcc9 in __GI_raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff7418c78 in wxGUIAppTraits::ShowAssertDialog (this=<optimised out>, msg=...) at ../src/gtk/utilsgtk.cpp:332
#2  0x00007ffff79c065a in ShowAssertDialog (file=..., line=line@entry=451, func=..., cond=..., msgUser=..., traits=traits@entry=0x861660) at ../src/common/appbase.cpp:1302
#3  0x00007ffff79c0ced in wxAppConsoleBase::OnAssertFailure (this=this@entry=0x7f1fe0, file=<optimised out>, line=451, func=<optimised out>, cond=<optimised out>, msg=<optimised out>) at ../src/common/appbase.cpp:781
#4  0x00007ffff73f2780 in wxApp::OnAssertFailure (this=0x7f1fe0, file=<optimised out>, line=<optimised out>, func=<optimised out>, cond=<optimised out>, msg=<optimised out>) at ../src/gtk/app.cpp:507
#5  0x00007ffff79c1081 in wxDefaultAssertHandler (file=..., line=line@entry=451, func=..., cond=..., msg=...) at ../src/common/appbase.cpp:1093
#6  0x00007ffff79be06c in wxOnAssert (file=file@entry=0x7ffff7b42bae "../include/wx/strvararg.h", line=line@entry=451, func=func@entry=0x7ffff7b4de70 <_ZZN15wxArgNormalizerImEC1EmPK14wxFormatStringjE12__FUNCTION__> "wxArgNormalizer",
    cond=cond@entry=0x7ffff7b43268 "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype", msg=msg@entry=0x7ffff7b43200 "format specifier doesn't match argument type") at ../src/common/appbase.cpp:1169
#7  0x00007ffff7a1a506 in wxArgNormalizer (index=2, fmt=0x7fffffffad90, value=10, this=<optimised out>) at ../include/wx/strvararg.h:451
#8  wxArgNormalizerWchar (index=2, fmt=0x7fffffffad90, value=10, this=<optimised out>) at ../include/wx/strvararg.h:471
#9  Log<wxString, unsigned long> (a2=10, a1=..., f1=..., this=0x7fffffffaf40) at ../include/wx/log.h:968
#10 wxFileConfig::Parse (this=this@entry=0xd19c90, buffer=..., bLocal=bLocal@entry=true) at ../src/common/fileconf.cpp:640
#11 0x00007ffff7a1e8f4 in wxFileConfig::wxFileConfig (this=0xd19c90, inStream=..., conv=...) at ../src/common/fileconf.cpp:498
#12 0x00000000004b5fc8 in ModList::ParseModIni(wxString const&, wxString const&, bool) ()
#13 0x00000000004b08c3 in ModList::ModList(wxWindow*, wxSize&, wxString) ()
#14 0x000000000049424b in ModsPage::OnTCChanged(wxCommandEvent&) ()
#15 0x00007ffff79bb11e in wxAppConsoleBase::CallEventHandler (this=0x7f1fe0, handler=0xb17530, functor=..., event=...) at ../src/common/appbase.cpp:623
#16 0x00007ffff7b2e282 in wxEvtHandler::ProcessEventIfMatchesId (entry=..., handler=<optimised out>, event=...) at ../src/common/event.cpp:1384
#17 0x00007ffff7b2e333 in wxEventHashTable::HandleEvent (this=<optimised out>, event=..., self=self@entry=0xb17530) at ../src/common/event.cpp:990
#18 0x00007ffff7b2e68d in wxEvtHandler::TryHereOnly (this=this@entry=0xb17530, event=...) at ../src/common/event.cpp:1581
#19 0x00007ffff7b2e703 in TryBeforeAndHere (event=..., this=this@entry=0xb17530) at ../include/wx/event.h:3671
#20 wxEvtHandler::ProcessEventLocally (this=this@entry=0xb17530, event=...) at ../src/common/event.cpp:1514
#21 0x00007ffff7b2e765 in wxEvtHandler::ProcessEvent (this=0xb17530, event=...) at ../src/common/event.cpp:1487
#22 0x00007ffff7b2f783 in wxEvtHandler::ProcessPendingEvents (this=0xb17530) at ../src/common/event.cpp:1351
#23 0x00007ffff79becd7 in wxAppConsoleBase::ProcessPendingEvents (this=0x7f1fe0) at ../src/common/appbase.cpp:520
#24 0x00007ffff73f0902 in wxApp::DoIdle (this=0x7f1fe0) at ../src/gtk/app.cpp:136
#25 0x00007ffff73f0a13 in wxapp_idle_callback () at ../src/gtk/app.cpp:107
#26 0x00007ffff3c73ce5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007ffff3c74048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x00007ffff3c7430a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x00007ffff4ee7447 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#30 0x00007ffff7403145 in wxGUIEventLoop::DoRun (this=0xf0fa30) at ../src/gtk/evtloop.cpp:65
#31 0x00007ffff79fd440 in wxEventLoopBase::Run (this=0xf0fa30) at ../src/common/evtloopcmn.cpp:78
#32 0x00007ffff79bd1fd in wxAppConsoleBase::MainLoop (this=0x7f1fe0) at ../src/common/appbase.cpp:334
#33 0x000000000051505e in wxLauncher::OnRun() ()
#34 0x00007ffff7a4904d in wxEntry (argc=<optimised out>, argv=<optimised out>) at ../src/common/init.cpp:495
#35 0x0000000000513fa6 in main ()

There's one more thing I've just noticed, the "taskbar" icon on Linux looks corrupted, it's a square mess of grey/static (the colour of a TV tuned to a dead channel, if you will...).
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: Iss Mneur on May 05, 2015, 10:18:53 pm
Well that was unhelpful. I wonder why it didn't include line numbers for wxLauncher code.

It looks like the mod.ini in WhatIf is malformed.  Can you please post it?
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: niffiwan on May 06, 2015, 03:56:04 am
Sure.

Code: [Select]
[launcher]
image255x112 = AGW_Logo.bmp;
infotext     = What If - Another Great War;
website      = http://www.junk-productions.de.vu/;
forum        = http://www.hard-light.net/forums/index.php/topic,56156.0.html;

[multimod]
primrylist = ;
secondrylist = SFS,fsport-mediavps,fsport,mediavps_3612;

[settings]
flags: -ship_choice_3d;

(I don't even remember where I got this mod from...)
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: Iss Mneur on May 06, 2015, 07:47:51 am
Sure.

Code: [Select]
[launcher]
image255x112 = AGW_Logo.bmp;
infotext     = What If - Another Great War;
website      = http://www.junk-productions.de.vu/;
forum        = http://www.hard-light.net/forums/index.php/topic,56156.0.html;

[multimod]
primrylist = ;
secondrylist = SFS,fsport-mediavps,fsport,mediavps_3612;

[settings]
flags: -ship_choice_3d;

(I don't even remember where I got this mod from...)

Remove the entire settings section. And your assert should go away. I wonder what put that there or what uses it because as far as I recall that is not defined in the mod.ini format
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: chief1983 on May 06, 2015, 10:14:09 am
I believe the Windows launcher respects it and forces that flag on, I could be wrong though.  Haven't seen it used in a while, and if that particular setting isn't configurable via the .tbl, it should be.
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: Iss Mneur on May 06, 2015, 11:29:07 pm
I believe the Windows launcher respects it and forces that flag on, I could be wrong though.  Haven't seen it used in a while, and if that particular setting isn't configurable via the .tbl, it should be.
Okay, that could be. But why a colon rather than an equals?  It seems to be the lack of equals that is causing wxWidgets the issue.
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: niffiwan on May 07, 2015, 02:50:54 am
I changed the colon to an equals in the mod.ini and the assertion is gone.

That just leaves the corrupt icon outstanding:
(http://i.imgur.com/NUrfpt5.png)
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: chief1983 on May 07, 2015, 07:20:21 am
When you switched it, did it have an effect on that flag?
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: Iss Mneur on May 07, 2015, 07:35:42 am
I am not sure that the icon has ever been set correctly on Linux.  I will have to look into how it is done.

Chief, it won' t have any effect in wxLauncher because it is not on the list of supported mod.INI entries; which reminds me, I still need to move the wiki over to github.
Title: Re: wxLauncher Test Builds [Updated: 2015-04-20]
Post by: niffiwan on May 07, 2015, 07:40:37 am
I am not sure that the icon has ever been set correctly on Linux.  I will have to look into how it is done.

I'm pretty sure it worked OK in 0.9.4.

When you switched it, did it have an effect on that flag?

I didn't actually test it, based on what Iss Mneur said I presumed that wxL wasn't going to process it. I'll see if I can give it a test tomorrow (for now is sleep.....zzzzzzzz)
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on March 19, 2016, 06:40:51 pm
BUMP Version 0.11.0 is available for beta testing.

0.11.0 fixes:
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: m!m on March 20, 2016, 11:12:23 am
I just tested the build with RC1 and a fresh antipodes build. Everything seems to be working properly and the config file contains the right values.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Makhpella on July 18, 2016, 09:50:39 am
Wasn't really sure where to post. Guess here'll do.

I downloaded .11, and other than the fact that I actually went and changed all mod images to 255x112 and the error that you'll see in the attachment, where is the play button?

[attachment deleted by admin]
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: AdmiralRalwood on July 18, 2016, 10:22:01 am
...Same place it's always been? Not sure why it's not showing up on yours.

[attachment deleted by admin]
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: tomimaki on July 18, 2016, 11:20:06 am
Same situation as Makhpella.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Makhpella on July 18, 2016, 11:54:24 am
Wouldn't have anything to do with the resolution, would it? I'm on 1366x768.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: m!m on July 18, 2016, 11:56:42 am
That's probably it. wxLauncher wasn't designed with resizing in mind so unfortunately these issues are quite common.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: tomimaki on July 18, 2016, 12:04:33 pm
I'm on 1366x768.
Me too.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on July 19, 2016, 09:24:15 am
I'm on 1366x768.
Me too.
Unfortunately, if I remember correctly, the screen needs to be more than 800 px tall to layout correctly. The layout code hasn't really been updated in a long time.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: tomimaki on July 19, 2016, 10:03:32 am
Then why 0.10.1 is ok, only 0.11.0 is broken?
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on July 19, 2016, 12:21:37 pm
That is interesting.  I will have to check then.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: niffiwan on July 19, 2016, 04:43:03 pm
I haven't tested to confirm, but I thought the vertical resolution increased in 0.11.0?
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on July 19, 2016, 11:17:39 pm
Apparently I don't remember correctly. The issue is with screens less than 650-700 px tall.  On these short monitors (think netbooks) there is not even space for the buttons, but yours has plenty of space.  Please run the debug build and post the log (instructions are in the OP).

niffiwan, something changed with the 0.11 because for me the launcher is expanding to the max vertical, but even when it does that the buttons are still stuck to the bottom of the content not just above the status bar like AdmiralRalwood.

I will have to make a point of looking into what can be done to fix the layout code.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: tomimaki on July 20, 2016, 10:01:59 am
Hm, debug build is 0.10.0. Should I use this? :nervous:
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on July 20, 2016, 04:03:58 pm
Hm, debug build is 0.10.0. Should I use this? :nervous:

Hrrm.

0.10.1 (which I just fixed the OP to link to) will work for what I am interested in.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: tomimaki on July 21, 2016, 11:20:32 am
Ok, here is log.

[attachment deleted by admin]
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on July 21, 2016, 12:32:32 pm
Code: [Select]
16203161155:DEBUG:I found 212 .ini files:
Really!?  I didn't think that many mods existed.



After reviewing the logs I am not seeing anything jump out at me (though I will have to test with 200 mod .ini's but that should not be causing our problem.

With 0.11.0 please check the basic settings page, and screenshot any dropdown boxes that are really long or drop below off the bottom of the screen.  In particular I am interested in the executable list and the sound card list.

Thanks,
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: jr2 on July 21, 2016, 12:38:08 pm
Code: [Select]
16203161155:DEBUG:I found 212 .ini files:
Really!?  I didn't think that many mods existed.



After reviewing the logs I am not seeing anything jump out at me (though I will have to test with 200 mod .ini's but that should not be causing our problem.

With 0.11.0 please check the basic settings page, and screenshot any dropdown boxes that are really long or drop below off the bottom of the screen.  In particular I am interested in the executable list and the sound card list.

Thanks,

I'm surprised those aren't dumped to the debug log already?
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on July 21, 2016, 12:47:28 pm
I'm surprised those aren't dumped to the debug log already?

They are (18xFSO.exe) and looks like 8 "sound cards", and neither of which should be too long, but something is pushing the buttons off the bottom.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: tomimaki on July 21, 2016, 03:32:41 pm
Some are not mods, just testing some stuff  :p
Anyway first run is weird because play button is still there, but after minimalizing or on second run it disappears.
Dropdown lists are normal. Weird is speech part.

[attachment deleted by admin]
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: T-Man on July 22, 2016, 06:00:01 pm
Are there any special requirements for a mod folder to be recognised in wxlauncher? I have one I've been working on which works fine on the old Launcher (and has a mod.ini etc) but doesn't appear in the mod list in wxlauncher. Others do including very old mods but not my one.

Cheers.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: niffiwan on July 22, 2016, 06:08:12 pm
I think you just need a mod.ini in a sub-folder, I've created a number of test mods which work fine with wxL.  Maybe post the contents of your mod.ini?
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: T-Man on July 22, 2016, 06:12:24 pm
I think you just need a mod.ini in a sub-folder, I've created a number of test mods which work fine with wxL.  Maybe post the contents of your mod.ini?

Okay. At the moment it's in a folder called 'Guiding_Star' and has a 'data' folder and mod.ini with this;
Code: [Select]
[launcher]
modname = Guiding Star;
infotext = As the last days of the Neo-Terran Front begin, the GTD Aeneas and 6th Fleet lead a slow bloody march into the NTF homeland of Polaris.;

[multimod]
primarylist  = ;
secondrylist = MediaVPs_2014;

I can load it through the older launcher fine, so I think it's working game-wise, it just isn't appearing for some reason (despite other folders with almost identical .inis also showing up).

EIDT: This is using the 0.10.1 beta btw. I grabbed it through Goob's installer.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: niffiwan on July 22, 2016, 06:57:29 pm
that seems quite similar to a working one I have:

Code: [Select]
# PLEASE NOTE ALL INI SETTINGS ARE *OPTIONAL*

# modname:       Display name only, so you can have spaces instead of underscores for multi word MOD's
# image255x112:  Location of a 255x112 bmp you wish to display in the launcher
# infotext:      Text that will appear in the launcher
# website:       Link to your website
# forum:         Link to your forum
[launcher]
modname      = CM Test (mvp)
#image255x112 = ;;bplogo.bmp;
image182x80 = mantis182.bmp;
infotext     = Testing Counter Measure Changes WITH mediavps
[multimod]
secondarylist = mediavps_2014;

Maybe update "secondrylist" to "secondarylist"?

Also, have you restarted wxL after creating/updating the mod.ini?
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: chief1983 on July 22, 2016, 07:49:16 pm
secondrylist should be fine due to reasons.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: niffiwan on July 22, 2016, 07:56:12 pm
yeah, I thought it should be ok as well (coders can't spell?  ;7), but in the absence of anything else obviously wrong... (I mean, maybe wxL didn't propagate the backwards compatibility spelling?)
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: T-Man on July 23, 2016, 02:47:14 am
(pardon slow reply; had to hit the sack)

Hadn't noticed that, sadly didn't work (checked through working mods and some of them had the misspelling too).

The good news is I finally got it working a moment ago; in the end I deleted the mod.ini and made a new one from scratch. Occoured to me I have had a couple of cases in the past where I've worked with text files and for some reason it hasn't recognised the new text till it's re-typed. It seemed to be if the info ended up in a slightly different font to the norm (not quite sure what caused it, assume it was times I was using wordpad not notepad or cut-pasting from word?).

Bad news is I'm a complete idiot and didn't think to preserve the broken one to compare and see what was breaking it. :banghead: If it ever happens again I'll be sure to preserve it.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: jr2 on July 23, 2016, 06:59:47 am
(pardon slow reply; had to hit the sack)

Hadn't noticed that, sadly didn't work (checked through working mods and some of them had the misspelling too).

The good news is I finally got it working a moment ago; in the end I deleted the mod.ini and made a new one from scratch. Occoured to me I have had a couple of cases in the past where I've worked with text files and for some reason it hasn't recognised the new text till it's re-typed. It seemed to be if the info ended up in a slightly different font to the norm (not quite sure what caused it, assume it was times I was using wordpad not notepad or cut-pasting from word?).

Bad news is I'm a complete idiot and didn't think to preserve the broken one to compare and see what was breaking it. :banghead: If it ever happens again I'll be sure to preserve it.

You  have file extensions un-hidden, right?   So you can see if you ended up with a mod.ini.txt?  To prevent it from occuring, either put quotes around the name+extension in the Save As dialog, or choose file type "all file types (*.*)" before saving.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on August 13, 2016, 06:14:52 pm
See the wxLauncher wiki on the mod options (https://github.com/scp-fs2open/wxLauncher/wiki/mod.ini%20options).  Basically, the only requirement is that a mod.ini exists in a folder, doesn't matter how deep.  Note that wxLauncher only scans for mods when it starts or when the TC selection is changed.

(Sorry, I realize this commentary is a bit late)
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on September 04, 2016, 10:10:04 pm
0.12.0-rc.2 has been posted.  Currently looking for some volunteers to produce the OS X build.

Should have fixed the issue with the bottom buttons vanishing (though they still disappear if the screen resolution is too low vertically or the DPI is too high).
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: chief1983 on September 05, 2016, 10:10:31 am
I can take a look at it.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: chief1983 on September 05, 2016, 02:57:13 pm
Ok, I had python installed, installed wxWidgets 3.0.2 with Homebrew because my OS is too new to compile 2.8.x, copied the SDL2.framework to my /Libraries/Frameworks folder, and CMake still complains that it can't find SDL2.

Code: [Select]
Checking for one of the modules 'sdl2'
CMake Error at /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindPkgConfig.cmake:646 (message):
  None of the required 'sdl2' found
Call Stack (most recent call first):
  CMakeLists.txt:152 (PKG_SEARCH_MODULE)

Not sure if including the log would help, it doesn't even contain the string 'sdl'.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: LaineyBugsDaddy on September 05, 2016, 03:10:53 pm
Ok, quick question. Is it only the post 3.7.4 builds that actually correctly identify attached game controllers once you have a binary selected in wxLauncher?
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: jg18 on September 05, 2016, 04:27:00 pm
EDIT: One sec, rereading.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: chief1983 on September 05, 2016, 04:32:36 pm
I copied the official sdl2 framework as that's the same as the archive one (or it should be), to /Library/Frameworks.  I'll try the user folder next chance I get.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: jg18 on September 05, 2016, 04:36:56 pm
I'll see if I can get the new wxL to build and run on OS X. I haven't made a build in a while and also not on El Capitan/Xcode 7. EDIT: Also haven't tried wxWidgets 3 before, so a bunch of new things to try.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: CT27 on September 05, 2016, 09:16:45 pm
Simple question I think:

If there's a new version just made, shouldn't the thread title be updated?  The thread title still says March 19.


EDIT:  Never mind, it was just the post title I saw.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: Iss Mneur on September 05, 2016, 09:29:10 pm
@chief1983: it looks like pkg-config can't find sdl2.

Looking at how the CI builds (https://github.com/scp-fs2open/wxLauncher/blob/master/ci/travis/install.sh) for OSX seems to be using brew to install sdl2 and other things.

@ct27: yep, oops.  Fixed now

@LaineyBugsDaddy: Yes, only FSO builds that have SDL will have the SDL joystick handling (though the useless name fix (where they were all called Joystick should apply either way).

I have not been tracking FSO development to know if the SDL code is in 3.7.4 or just in the nightlys.
Title: Re: wxLauncher Test Builds [Updated: 2016-03-19]
Post by: jg18 on September 06, 2016, 01:12:56 am
@chief1983: it looks like pkg-config can't find sdl2.

Looking at how the CI builds (https://github.com/scp-fs2open/wxLauncher/blob/master/ci/travis/install.sh) for OSX seems to be using brew to install sdl2 and other things.

I have not been tracking FSO development to know if the SDL code is in 3.7.4 or just in the nightlys.
I'm not sure pkg-config is the right way on OS X> I think CMake should be able to find SDL2.framework if you put it in the right place and tell it where it is. At least that's how it worked with SDL.framework. However it doesn't seem to work with SDL2.framework, and so far I'm not sure if the issue is with SDL2 or more recent versions of CMake or more recent versions of OS X (Xcode?).

Or alternatively, maybe wxL actually was using an OS X system copy of SDL rather than the provided SDL.framework and I've misunderstood the entire time? :confused: Time to do an otool -L (OS X equivalent of Linux's ldd) and see what the wxL executable is linked against. EDIT: otool -L confirms that the wxL executable on OS X is linked against the provided SDL.framework and not some OS X system copy of SDL. Phew.

I'm thinking the CMakeLists.txt will need some tweaking to work for OS X. I've spent some time looking into it but not much progress so far. It also looks like the ReadMe's build instructions for OS X are in serious need of an update; I'll need to fix that.

Also SDL2 is just in the nightlies, not 3.7.4.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 06, 2016, 09:42:44 am
For what it's worth, I got wxLauncher to configure, but it won't build.  I attempted to build a Release build (I had configured CMake to default to Release before running this command).

Code: [Select]
cliffgordon@cliffmbp:~/wxLauncher/build [master]  $ xcodebuild -configuration Release
=== BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT wxlauncher WITH CONFIGURATION Release ===

Check dependencies

Write auxiliary files
write-file /Users/cliffgordon/wxLauncher/build/wxlauncher.build/Release/ZERO_CHECK.build/Script-67EF77E1D4984A3F9D5BD4DD.sh
chmod 0755 /Users/cliffgordon/wxLauncher/build/wxlauncher.build/Release/ZERO_CHECK.build/Script-67EF77E1D4984A3F9D5BD4DD.sh

PhaseScriptExecution CMake\ Rules build/wxlauncher.build/Release/ZERO_CHECK.build/Script-67EF77E1D4984A3F9D5BD4DD.sh
    cd /Users/cliffgordon/wxLauncher
    /bin/sh -c /Users/cliffgordon/wxLauncher/build/wxlauncher.build/Release/ZERO_CHECK.build/Script-67EF77E1D4984A3F9D5BD4DD.sh
echo ""

make -f /Users/cliffgordon/wxLauncher/build/CMakeScripts/ReRunCMake.make
make[1]: `/Users/cliffgordon/wxLauncher/build/CMakeFiles/cmake.check_cache' is up to date.

=== BUILD AGGREGATE TARGET helpmaker OF PROJECT wxlauncher WITH CONFIGURATION Release ===

Check dependencies

Write auxiliary files
write-file /Users/cliffgordon/wxLauncher/build/wxlauncher.build/Release/helpmaker.build/Script-37301D1C165B455EAED2C838.sh
chmod 0755 /Users/cliffgordon/wxLauncher/build/wxlauncher.build/Release/helpmaker.build/Script-37301D1C165B455EAED2C838.sh

PhaseScriptExecution CMake\ Rules build/wxlauncher.build/Release/helpmaker.build/Script-37301D1C165B455EAED2C838.sh
    cd /Users/cliffgordon/wxLauncher
    /bin/sh -c /Users/cliffgordon/wxLauncher/build/wxlauncher.build/Release/helpmaker.build/Script-37301D1C165B455EAED2C838.sh
echo ""

cd /Users/cliffgordon/wxLauncher && /usr/local/bin/python scripts/onlinehelpmaker.py -q build /Users/cliffgordon/wxLauncher/build/generated/onlinehelp.htb /Users/cliffgordon/wxLauncher/onlinehelp -t /Users/cliffgordon/wxLauncher/build/onlinehelpmaker -c /Users/cliffgordon/wxLauncher/build/generated/helplinks.cpp
Traceback (most recent call last):
  File "scripts/onlinehelpmaker.py", line 9, in <module>
    from ohm.utilfunctions import rmtree_error_handler
  File "/Users/cliffgordon/wxLauncher/scripts/ohm/utilfunctions.py", line 6, in <module>
    from builtins import *
ImportError: No module named builtins
make: *** [/Users/cliffgordon/wxLauncher/build/CMakeFiles/helpmaker] Error 1
Command /bin/sh failed with exit code 2

** BUILD FAILED **


The following build commands failed:
PhaseScriptExecution CMake\ Rules build/wxlauncher.build/Release/helpmaker.build/Script-37301D1C165B455EAED2C838.sh
(1 failure)

Edit:  I got past that by commenting out the builtins import * line in two different python files.  Not sure it's necessary on Python 2.7 at least.  But then I run into a ton of undefined symbol errors for wxWidgets and SDL2 symbols.  So configuring went fine, but compiling won't now.  Also, should mention how I got it to configure.  I didn't use the SDL2.frameworks file after I all, I just installed SDL2 with brew like I installed wxWidgets.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 06, 2016, 10:06:06 am
On a hunch, how do I force wxLauncher to only build x86_64 instead of i386?  I'll look around for how but if someone knows it might help.  I don't think libs typically work with 32bit stuff these days as Mac has been 64-bit only for years now.

Edit: In the interim of figuring out how to make CMake do this (CMAKE_OSX_ARCHITECTURES doesn't seem to work for me), I modified the generated XCode project.  Now I get the following during the build process.

Code: [Select]
Ld build/Release/wxlauncher.app/Contents/MacOS/wxlauncher normal x86_64
    cd /Users/cliffgordon/wxLauncher
    export MACOSX_DEPLOYMENT_TARGET=10.11
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -L/Users/cliffgordon/wxLauncher/build/Release -L/usr/local/lib/Release -L/usr/local/lib -F/Users/cliffgordon/wxLauncher/build/Release -filelist /Users/cliffgordon/wxLauncher/build/wxlauncher.build/Release/wxlauncher.build/Objects-normal/x86_64/wxlauncher.LinkFileList -Xlinker -rpath -Xlinker /usr/local/lib -mmacosx-version-min=10.11 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/lib -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL /usr/local/lib/libwx_baseu_net-3.0.a /usr/local/lib/libwx_osx_cocoau_qa-3.0.a /usr/local/lib/libwx_osx_cocoau_richtext-3.0.a /usr/local/lib/libwx_osx_cocoau_html-3.0.a /usr/local/lib/libwx_osx_cocoau_adv-3.0.a /usr/local/lib/libwx_osx_cocoau_core-3.0.a /usr/local/lib/libwx_baseu_xml-3.0.a /usr/local/lib/libwx_baseu-3.0.a -lpng -ljpeg -ltiff -framework WebKit -lexpat -lwxregexu-3.0 -lz -lpthread -liconv -lSDL2 -Xlinker -dependency_info -Xlinker /Users/cliffgordon/wxLauncher/build/wxlauncher.build/Release/wxlauncher.build/Objects-normal/x86_64/wxlauncher_dependency_info.dat -o /Users/cliffgordon/wxLauncher/build/Release/wxlauncher.app/Contents/MacOS/wxlauncher
ld: warning: directory not found for option '-L/usr/local/lib/Release'

PhaseScriptExecution CMake\ PostBuild\ Rules build/wxlauncher.build/Release/wxlauncher.build/Script-2A8E10E75501468DBFB1B53B.sh
    cd /Users/cliffgordon/wxLauncher
    /bin/sh -c /Users/cliffgordon/wxLauncher/build/wxlauncher.build/Release/wxlauncher.build/Script-2A8E10E75501468DBFB1B53B.sh
rm -rf /Users/cliffgordon/wxLauncher/build/Release/wxlauncher.app/Contents/Resources
rm -rf /Users/cliffgordon/wxLauncher/build/Release/wxlauncher.app/Contents/Frameworks
mkdir /Users/cliffgordon/wxLauncher/build/Release/wxlauncher.app/Contents/Resources
mkdir /Users/cliffgordon/wxLauncher/build/Release/wxlauncher.app/Contents/Frameworks
cp /Users/cliffgordon/wxLauncher/resources/* /Users/cliffgordon/wxLauncher/build/Release/wxlauncher.app/Contents/Resources
cp /Users/cliffgordon/wxLauncher/build/generated/onlinehelp.htb /Users/cliffgordon/wxLauncher/build/Release/wxlauncher.app/Contents/Resources
cp /Users/cliffgordon/wxLauncher/platform/macosx/wxlauncher.icns /Users/cliffgordon/wxLauncher/build/Release/wxlauncher.app/Contents/Resources
cp -R /Users/cliffgordon/wxLauncher/build/Release/wxlauncher.app/Contents/Frameworks
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-apvX] source_file target_file
       cp [-R [-H | -L | -P]] [-f | -i | -n] [-apvX] source_file ... target_directory
make: *** [wxlauncher_buildpart_1] Error 64
Command /bin/sh failed with exit code 2

It seems to be missing the source argument for a copy command.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 06, 2016, 08:05:27 pm
Sorry, I have no idea.  Though for some reason CI builds with cmake (https://github.com/scp-fs2open/wxLauncher/blob/master/ci/travis/script.sh).  Unfortunately, I don't know why it works, it was contributed by m!m, maybe he can elaborate.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 07, 2016, 01:56:42 am
It's trying to copy the SDL2.framework into the wxL app bundle, based on the assumption that you're linking against the framework. If you're statically linking against an SDL2 library you built using Homebrew then you can comment out that entire section of commands from the CMakeLists.txt.

Good point that wxL should be 64-bit on OS X. Not sure if setting CMAKE_OSX_ARCHITECTURES in CMakeLists.txt to x86_64 is enough.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: m!m on September 07, 2016, 03:09:47 am
Sorry, I have no idea.  Though for some reason CI builds with cmake (https://github.com/scp-fs2open/wxLauncher/blob/master/ci/travis/script.sh).  Unfortunately, I don't know why it works, it was contributed by m!m, maybe he can elaborate.
CMake just calls the native build tool (in this case xcodebuild).
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 07, 2016, 07:50:39 am
CMake just calls the native build tool (in this case xcodebuild).
Fair enough, I wasn't sure if it setup an environment before calling the native tool, because it appears to be where the x64 arch is set.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 07, 2016, 09:37:29 am
I wasn't statically linking I don't think, the SDL2 installed by brew was 'bottled', it didn't build it, it downloaded an existing bundle of some sort and installed it to /usr/local/Cellar/sdl2.  Somehow CMake managed to find it there but not the official bundle in /Library/Frameworks.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 12, 2016, 10:04:43 pm
Some progress on wxL for OS X but still not there. :sigh:

Both wxWidgets and wxL are now 64-bit.

I put SDL2.framework from the FSO source tree in ~/Library/Frameworks.

I tried both wxWidgets 3.0.2 and 3.1.0, downloading them from wxwidgets.org.

In both cases, here’s what I did starting from the wxWidgets root folder:

Code: [Select]
mkdir build-debug
cd build-debug
../configure --enable-stl --enable-unicode --enable-debug --disable-shared --with-macosx-version-min=10.7 CC=clang CXX=clang++ CXXFLAGS="-stdlib=libc++ -std=c++11" OBJCXXFLAGS="-stdlib=libc++ -std=c++11" LDFLAGS=-stdlib=libc++

I think I have to use clang instead of g++ if I want C++11 support while maintaining OS X 10.7 compatibility.

The compiler/linker flags were from this thread (https://forums.wxwidgets.org/viewtopic.php?t=37432) after I was getting linking errors when trying to build wxL.

I then made the following changes to CMakeLists.txt in wxL to get it to find and link with SDL2.framework and also set compatibility mode to 10.7. (Although the info.plist inside the wxlauncher app bundle doesn’t mention 10.7 as the minimum version so maybe I did it wrong.)

Code: [Select]
diff --git a/CMakeLists.txt b/CMakeLists.txt
index bfad077..1731124 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -22,8 +22,6 @@ include(${3RD_PARTY_SOURCE_DIR}/GetVersionFromGitTag.cmake)
 
 message("--- Configuring wxLauncher ${wxlauncher_VERSION_STRING_FULL}")
 
-set(CMAKE_OSX_ARCHITECTURES i386)
-
 if(NOT(DEFINED IS_WIN32 OR DEFINED IS_LINUX OR DEFINED IS_APPLE))
   if(WIN32)
     set(IS_WIN32 TRUE)
@@ -146,7 +144,16 @@ if(USE_OPENAL)
   include_directories(${OPENAL_INCLUDE_DIR})
 endif(USE_OPENAL)
 
-IF(UNIX)
+if(IS_APPLE)
+    set(CMAKE_OSX_DEPLOYMENT_TARGET 10.7)
+    find_library(SDL2_FRAMEWORK SDL2)
+#    if (NOT SDL2_FRAMEWORK)
+#        message(FATAL_ERROR “SDL2 not found")
+#    endif()
+    set(SDL2_INCLUDES ${SDL2_FRAMEWORK}/Headers)
+    set(SDL2_LIBRARIES ${SDL2_FRAMEWORK})
+
+elseIF(UNIX)
     INCLUDE(FindPkgConfig)
 
     PKG_SEARCH_MODULE(SDL2 REQUIRED sdl2)
@@ -341,9 +348,11 @@ add_executable(wxlauncher WIN32 MACOSX_BUNDLE
   ${RESOURCE_FILES}
   ${CODE_FILES}
   )
-if (COMMAND target_compile_features)
-  target_compile_features(wxlauncher PRIVATE cxx_auto_type) # Enable C++11 because it is required for wxWidgets 3.0
-endif()
+
+# FIXME TODO with Clang on OS X use CXX FLAGS
+#if (COMMAND target_compile_features)
+#  target_compile_features(wxlauncher PRIVATE cxx_auto_type) # Enable C++11 because #it is required for wxWidgets 3.0
+#endif()
   
 set_target_properties(wxlauncher
   PROPERTIES LINKER_LANGUAGE CXX
@@ -383,7 +392,7 @@ if(IS_APPLE)
     COMMAND cp ${PROJECT_SOURCE_DIR}/platform/macosx/wxlauncher.icns ${APP_RESOURCES_PATH})
   if(USING_SDL_FRAMEWORK) # then copy the framework into the app
     add_custom_command(TARGET wxlauncher POST_BUILD
-      COMMAND cp -R ${SDL_LIBRARY} ${APP_FRAMEWORKS_PATH})
+      COMMAND cp -R ${SDL2_FRAMEWORK} ${APP_FRAMEWORKS_PATH})
   endif(USING_SDL_FRAMEWORK)
 endif(IS_APPLE)

(I need to fix generating an error when SDL2 can't be found, haven't gotten around to that yet.)

Then from the wxL repo root  folder I ran this:
Code: [Select]
mkdir build
cd build
/Applications/CMake.app/Contents/bin/cmake -G Xcode -DwxWidgets_CONFIG_EXECUTABLE=/PATH/TO/wxWidgetsFolder/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++ ../

I couldn’t get the Python scripts to work with Python 2, something about no module named ‘builtins’ so I got Python 3 from python.org.

With all of this, wxL builds successfully.

However when I run it, there’s no window and I have to force quit wxL.

Running the wxL Unix executable insside the app bundle from the command line produces this output:

Code: [Select]
$ /path/to/wxLauncherRepo/build/Debug/wxlauncher.app/Contents/MacOS/wxlauncher ; exit;
2016-09-12 19:14:46.951 wxlauncher[54989:120699] _createMenuRef called with existing principal MenuRef already associated with menu
2016-09-12 19:14:46.953 wxlauncher[54989:120699] (
0   CoreFoundation                      0x00007fff8f9f64f2 __exceptionPreprocess + 178
1   libobjc.A.dylib                     0x00007fff838e3f7e objc_exception_throw + 48
2   CoreFoundation                      0x00007fff8fa5d4bd +[NSException raise:format:] + 205
3   AppKit                              0x00007fff86c13c86 -[NSCarbonMenuImpl _createMenuRef] + 62
4   AppKit                              0x00007fff86c135c5 -[NSCarbonMenuImpl _instantiateCarbonMenu] + 140
5   AppKit                              0x00007fff86c11270 -[NSApplication finishLaunching] + 856
6   AppKit                              0x00007fff86c10bbd -[NSApplication run] + 231
7   wxlauncher                          0x0000000103b8eaad _ZN5wxApp10CallOnInitEv + 349
8   wxlauncher                          0x0000000103ee53c0 _Z7wxEntryRiPPw + 192
9   wxlauncher                          0x0000000103ee558c _Z7wxEntryRiPPc + 60
10  wxlauncher                          0x0000000103aecfd0 main + 240
11  wxlauncher                          0x00000001039dc1f4 start + 52
12  ???                                 0x0000000000000001 0x0 + 1
)

For all I know the error is just from trying to run the Unix executable this way and isn’t actually the real problem.

No wxLauncher.log is produced. Looking in ~/Library/Application Support/wxlauncher/ .

Any thoughts from anyone?

Perhaps the compiler warnings from building wxWidgets and/or wxL could provide some insight into the problem. Haven't taken a close look at them yet.

EDIT: Correction.

EDIT 2: Not sure that CPack is configured correctly for OS X anymore. Looked like DragNDrop mode is off, although the build produced what looks like a drag and drop app.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 12, 2016, 10:54:55 pm
That's odd.  I went a completely different route than you but ended up with the same result, an app that doesn't create a window and must be force quit.  I used wxmac, sdl2 from homebrew, deleted the builtin lines in the python scripts, and modified the build archs using the command line from the Travis scripts.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: mjn.mixael on September 13, 2016, 05:02:28 pm
Randomly, I've noticed that wxL does not show it's own version anywhere as far as I can tell. This might be a useful little piece of info to make visible somewhere.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 13, 2016, 05:06:21 pm
On Mac at least, 0.12 has an about dialog with it.  Not sure if windows has that.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 15, 2016, 01:52:21 pm
Issue tracked down. It was a conflict between SDL2 initializeing and wxWidgets initializing. Apparently only happens on OS X with wxWidgets 3.x.

Best solution IMO is to initialize SDL Video only when we need it to detect resolutions, rather than trying to initialize it at wxL startup. wxL works correctly on OS X when this change is made.

I do not recommend using SDL_Init() because according to the  SDL Wiki (https://wiki.libsdl.org/SDL_Init) it initializes subsystems that we never use like File I/O and Threads. IMO it’s best to just initialize the subsystems we actually need.

If we make this change, then we need to decide when to shut the SDL video subsystem down. Two options:
- right after we’re done detecting resolutions, similar to how SDL joystick subsystem is initialized right before detecting joysticks and shut down right after detecting joysticks. It does mean we’d be repeatedly initializing and shutting down the SDL video subsystem as wxL runs, dunno if that’s an issue. We already do just that with the SDL joystick subsystem.
- when shutting down wxL, something like the following in wxLauncher::OnExit():
Code: [Select]
#if HAS_SDL == 1
Uint32 initedSubsystems = SDL_WasInit(0);
if (initedSubsystems) {
SDL_QuitSubSystem(initedSubsystems);
}
#endif
We could shut down the SDL joystick subsystem the same way (that is, at wxL exit) rather than repeatedly initializing/quitting it.


On a related note, why are we still using Win32 API to detect resolutions on Windows? If we’re using SDL everywhere then why not use SDL on all platforms for resolution detection?

Also apparently the SDL joystick subsystem was being initialized without checking the return value from SDL_InitSubsystem(), so we weren’t checking if the init actually succeeded. :wtf: Might as well fix that too while tinkering with the SDL code.


Here is a patch that initializes SDL video before detecting resolutions and shuts it down right after detecting resolutions (that is, option #1 mentioned above). Since SDL is no longer being initialized at wxL startup, we can remove the custom main() function, so I did that as well.

Tested on OS X, needs testing on Windows/Linux. I’ll try to get around to it if someone else doesn’t first.

EDIT 3: Patch doesn't work on Linux, see this post (http://www.hard-light.net/forums/index.php?topic=89162.msg1829795#msg1829795) for updated patch.

One known issue: looks like the top bar menu on OS X for wxL is empty, meaning no About dialog. I don't feel like this is worth trying to fix and is probably something in wxWidgets anyway.

While testing on OS X, I got a couple crashes on wxL shutdown. Here’s  a patch to plug those holes:

Code: [Select]
diff --git a/code/apis/ProfileManager.h b/code/apis/ProfileManager.h
index 0990057..d567be2 100644
--- a/code/apis/ProfileManager.h
+++ b/code/apis/ProfileManager.h
@@ -55,6 +55,7 @@ public:
  };
  static bool Initialize(Flags flags = None);
  static bool DeInitialize();
+ static bool IsInitialized() { return isInitialized; }
  static ProMan* GetProfileManager();
 
  virtual ~ProMan();
diff --git a/code/apis/TCManager.cpp b/code/apis/TCManager.cpp
index 6afde00..078e7de 100644
--- a/code/apis/TCManager.cpp
+++ b/code/apis/TCManager.cpp
@@ -35,7 +35,9 @@ TCManager::TCManager() {
 }
 /** Destructor. Static class does nothing. */
 TCManager::~TCManager() {
- ProMan::GetProfileManager()->RemoveEventHandler(this);
+ if (ProMan::IsInitialized()) {
+ ProMan::GetProfileManager()->RemoveEventHandler(this);
+ }
 }
 
 TCManager* TCManager::manager = NULL;
diff --git a/code/controls/ModList.cpp b/code/controls/ModList.cpp
index 3195ab8..c290cb5 100644
--- a/code/controls/ModList.cpp
+++ b/code/controls/ModList.cpp
@@ -604,7 +604,9 @@ ModList::ModList(wxWindow *parent, wxSize& size, wxString tcPath)
 
 /** the dtor.  Cleans up stuff. */
 ModList::~ModList() {
- SkinSystem::UnRegisterTCSkinChanged(this);
+ if (SkinSystem::IsInitialized()) {
+ SkinSystem::UnRegisterTCSkinChanged(this);
+ }
 
  if ( this->configFiles != NULL ) {
  delete this->configFiles;


Once this is sorted out we can work on getting CMakeLists.txt updated to support OS X again, and I can also update the ReadMe with current build instructions for OS X.

Randomly, I've noticed that wxL does not show it's own version anywhere as far as I can tell. This might be a useful little piece of info to make visible somewhere.
I think it's printed to the log but yeah it'd probably be good to show it somewhere in the GUI. A cross-platform About dialog would be a considerable amount of work. Maybe we could stick it in the default window title? As in "wxLauncher 0.12.0-rc2 for the FreeSpace 2 Source Code PRoject". Not sure offhand how hard that would be to do, probably not very though. EDIT: Or maybe display it prominently in the Help manual? Displaying it in the default window title isn't foolproof because TCs (and maybe also mods, I forget) can change the window title through the skin system.


EDIT 2: While we're fixing stuff in wxL, could also fix that annoying bug in displaying build versions where certain commit hashes don't appear in the GUI. I have a patch for it somewhere in the nightly builds forum, would have to dig it up.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 15, 2016, 03:12:53 pm
I was able to get an About dialog to open up on my Mac the other day, using the top menu bar.  I can't with the 0.10.x version but I did with my build of 0.12.0, even though there was no program window.  I could still interact with the top menu, and opened an About dialog with a version number in it.

Edit:  (https://photos-6.dropbox.com/t/2/AABRR5c_AQ7uXZnm3DwHxlTX89iNn4WJbtoWlGYqAVz7kA/12/63963020/png/32x32/1/_/1/2/Screenshot%202016-09-15%2015.13.33.png/EMLUzTEY5wEgAigCKAQ/MKPG-fumn48N9GqtPQcwTfri6oERfGtrXrB627y4BB0?size=1280x960&size_mode=3)
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: AdmiralRalwood on September 15, 2016, 04:06:20 pm
[img]https://photos-6.dropbox.com/t/2/AABRR5c_AQ7uXZnm3DwHxlTX89iNn4WJbtoWlGYqAVz7kA/12/63963020/png/32x32/1/_/1/2/Screenshot%202016-09-15%2015.13.33.png/EMLUzTEY5wEgAigCKAQ/MKPG-fumn48N9GqtPQcwTfri6oERfGtrXrB627y4BB0?size=1280x960&size_mode=3[/img]
That URL gives me a 403 error.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 15, 2016, 04:44:45 pm
I keep forgetting Dropbox doesn't like that
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 16, 2016, 12:10:43 am
I do not recommend using SDL_Init() because according to the  SDL Wiki (https://wiki.libsdl.org/SDL_Init) it initializes subsystems that we never use like File I/O and Threads. IMO it’s best to just initialize the subsystems we actually need.
Agreed. Espcially since wxWidgets has its own versions that we are already using.

If we make this change, then we need to decide when to shut the SDL video subsystem down. Two options:
- right after we’re done detecting resolutions [snip]
- when shutting down wxL [snip]
My only concern with initializing once on start up, would be "hotplug" detecting changes to the resolution capabilities.  I could not find any information on if this is actually a concern.  Otherwise either option works for me.

On a related note, why are we still using Win32 API to detect resolutions on Windows? If we’re using SDL everywhere then why not use SDL on all platforms for resolution detection?
Because it was missed when support for SDL joysticks was added. The laucher should use the API that FSO will be using, just like with the joysticks.

Tested on OS X, needs testing on Windows/Linux. I’ll try to get around to it if someone else doesn’t first.
I can try it on Windows tomorrow evening.

One known issue: looks like the top bar menu on OS X for wxL is empty, meaning no About dialog. I don't feel like this is worth trying to fix and is probably something in wxWidgets anyway.

Randomly, I've noticed that wxL does not show it's own version anywhere as far as I can tell. This might be a useful little piece of info to make visible somewhere.
I think it's printed to the log but yeah it'd probably be good to show it somewhere in the GUI. A cross-platform About dialog would be a considerable amount of work. Maybe we could stick it in the default window title? As in "wxLauncher 0.12.0-rc2 for the FreeSpace 2 Source Code PRoject". Not sure offhand how hard that would be to do, probably not very though. EDIT: Or maybe display it prominently in the Help manual? Displaying it in the default window title isn't foolproof because TCs (and maybe also mods, I forget) can change the window title through the skin system.
There is supposed to be an about button beside the help button, bits of the code for it are even still in the code base.  It is just one of those features that has yet to be completed.

Only TCs should be able to change the title bar, though I don't recall if they can change the entire thing or just the bit after wxLauncher.

Trying to figure out what to do with the online help.  It hasn't even been updated recently and still references 0.9.0 as the newest version (and is utterly broken in 0.12.0-rc.2, since fixed in master).  Will probably end up doing something with the wiki(s) and the github releases api.  But also may just remove it and have help drop a person on a suitable landing page on the wxLauncher wiki.

EDIT 2: While we're fixing stuff in wxL, could also fix that annoying bug in displaying build versions where certain commit hashes don't appear in the GUI. I have a patch for it somewhere in the nightly builds forum, would have to dig it up.
I had not heard of this one.  Do we have any examples of hashes that don't appear?
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 16, 2016, 12:49:21 am
Here's that about dialog (https://www.dropbox.com/s/825munph2l2vwkr/Screenshot%202016-09-15%2015.13.33.png?dl=0)  Maybe this will work?
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 16, 2016, 03:00:56 am
If we make this change, then we need to decide when to shut the SDL video subsystem down. Two options:
- right after we’re done detecting resolutions [snip]
- when shutting down wxL [snip]
My only concern with initializing once on start up, would be "hotplug" detecting changes to the resolution capabilities.  I could not find any information on if this is actually a concern.  Otherwise either option works for me.
Well the patch I posted above initializes SDL video every time resolution detection is needed and shuts it down right afterwards so might as well go with that approach.

On a related note, why are we still using Win32 API to detect resolutions on Windows? If we’re using SDL everywhere then why not use SDL on all platforms for resolution detection?
Because it was missed when support for SDL joysticks was added. The laucher should use the API that FSO will be using, just like with the joysticks.
Ok. Maybe not worth fixing for 0.12.0 given that it’d involve non-trivial changes to support both Win32 and SDL resolution detection on Windows?


Tested on OS X, needs testing on Windows/Linux. I’ll try to get around to it if someone else doesn’t first.
I can try it on Windows tomorrow evening.
Ok, I’ll try it on Linux. I got the Ubuntu GNOME 16.04.1 ISO and can set it up in VMWare.

One known issue: looks like the top bar menu on OS X for wxL is empty, meaning no About dialog. I don't feel like this is worth trying to fix and is probably something in wxWidgets anyway.

Randomly, I've noticed that wxL does not show it's own version anywhere as far as I can tell. This might be a useful little piece of info to make visible somewhere.
I think it's printed to the log but yeah it'd probably be good to show it somewhere in the GUI. A cross-platform About dialog would be a considerable amount of work. Maybe we could stick it in the default window title? As in "wxLauncher 0.12.0-rc2 for the FreeSpace 2 Source Code PRoject". Not sure offhand how hard that would be to do, probably not very though. EDIT: Or maybe display it prominently in the Help manual? Displaying it in the default window title isn't foolproof because TCs (and maybe also mods, I forget) can change the window title through the skin system.
There is supposed to be an about button beside the help button, bits of the code for it are even still in the code base.  It is just one of those features that has yet to be completed.
Yeah, and since finishing it is probably a significant amount of work, maybe something quicker like putting the version in the default window title is worth doing, possibly even for 0.12.0?

Only TCs should be able to change the title bar, though I don't recall if they can change the entire thing or just the bit after wxLauncher.
I think they can change the entire window title, which IMO is fine. FOr example Diaspora might as well put the window title as “Diaspora Launcher” or “Launch Diaspora” or something that doesn’t mention wxLauncher. I don’t feel like they have to explicitly mention that it’s wxLauncher. Not that important though TBH.

Trying to figure out what to do with the online help.  It hasn't even been updated recently and still references 0.9.0 as the newest version (and is utterly broken in 0.12.0-rc.2, since fixed in master).  Will probably end up doing something with the wiki(s) and the github releases api.  But also may just remove it and have help drop a person on a suitable landing page on the wxLauncher wiki.
Removing the help system and making the Help button point people to the wiki makes sense to me. It’s easier to keep the wiki up-to-date than the help system. Also means we can get rid of the Python scripts/dependency I think?

EDIT 2: While we're fixing stuff in wxL, could also fix that annoying bug in displaying build versions where certain commit hashes don't appear in the GUI. I have a patch for it somewhere in the nightly builds forum, would have to dig it up.
I had not heard of this one.  Do we have any examples of hashes that don't appear?
Here you go. (http://www.hard-light.net/forums/index.php?topic=92180.0)

While I’m cranking out patches, here’s one to fix the copyright symbol that appears when you right-click on wxlauncher.app in OS X and select Get Info:
Code: [Select]
diff --git a/cmake/wxLauncherInstaller.cmake b/cmake/wxLauncherInstaller.cmake
index 6ad1885..e1d91f6 100644
--- a/cmake/wxLauncherInstaller.cmake
+++ b/cmake/wxLauncherInstaller.cmake
@@ -71,7 +71,7 @@ if(IS_APPLE)
 #  set(MACOSX_BUNDLE_LONG_VERSION_STRING "wxLauncher for the SCP, version ${MACOSX_BUNDLE_SHORT_VERSION_STRING}")
   set(MACOSX_BUNDLE_ICON_FILE wxlauncher.icns)
   set(MACOSX_BUNDLE_SHORT_VERSION_STRING ${wxlauncher_VERSION})
-  set(MACOSX_BUNDLE_COPYRIGHT "Copyright � 2009-2016 ${CPACK_PACKAGE_VENDOR}")
+  set(MACOSX_BUNDLE_COPYRIGHT "Copyright © 2009-2016 ${CPACK_PACKAGE_VENDOR}")
 endif(IS_APPLE)
 
 if(IS_LINUX)
I don’t think there’s any equivalent of this copyright string on other platforms. Dunno if it’s worth looking into or if it’s even possible.

Here's that about dialog (https://www.dropbox.com/s/825munph2l2vwkr/Screenshot%202016-09-15%2015.13.33.png?dl=0)  Maybe this will work?
Pretty sure that dialog is  auto-generated by OS X and does not appear on other platforms. When I build wxL using SDL2.framework, wxWidgets 3.0.2 and the patch I posted above, when you click on the “wxlauncher” top menubar, the menu is empty. You can try the patch on your own setup and  see if that’s the case for you as well.


Also, is the patch I posted above to fix the crashes when exiting wxL good to commit? I don't think I have commit access to wxL. Maybe we could collect all of these patches as separate commits into a single PR when we're done (including updating CMakeLists.txt and the ReadMe)? Admittedly a PR labeled "Fix various things" or the like sounds sloppy, even if the individual commits are fine. *shrug*
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 16, 2016, 04:32:54 am
Here's something I whipped up to put the version in the default window title.

I tried putting the VERSION_STRING as a const wxString within version.cpp and making it an extern const wxString in version.h but could not for the life of me get it to work. :mad: The VERSION_STRING always appeared as empty and i could not figure out why. That is, the window title always appeared as "wxLauncher  for the FreeSpace 2 Source Code Project". Note the extra space after "wxLauncher". With the patch below though it appears correctly.

Code: [Select]
diff --git a/code/global/SkinDefaults.cpp b/code/global/SkinDefaults.cpp
index 2ea8649..bb0b86d 100644
--- a/code/global/SkinDefaults.cpp
+++ b/code/global/SkinDefaults.cpp
@@ -17,9 +17,13 @@
  */
 
 #include "SkinDefaults.h"
+#include "version.h"
 #include <wx/intl.h> // for _() macro
 
-const wxString DEFAULT_SKIN_WINDOW_TITLE (_("wxLauncher for the FreeSpace 2 Source Code Project"));
+// not needed externally
+static const wxString VERSION_STRING(wxString::Format(_T("%d.%d.%d"), MAJOR_VERSION, MINOR_VERSION, PATCH_VERSION));
+
+const wxString DEFAULT_SKIN_WINDOW_TITLE (wxString::Format(_T("wxLauncher %s for the FreeSpace 2 Source Code Project"), VERSION_STRING.c_str()));
 const wxString DEFAULT_SKIN_WINDOW_ICON (_T("wxlauncher.ico"));
 const wxString DEFAULT_SKIN_BANNER (_T("SCP_Header.png"));
 const wxString DEFAULT_SKIN_WELCOME_TEXT
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 16, 2016, 07:13:09 am
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 16, 2016, 08:30:32 am
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 16, 2016, 08:41:18 am
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 16, 2016, 06:53:57 pm
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? :D

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 :ick: 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?
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 16, 2016, 07:11:04 pm
That was without the patch, haven't had a chance to test it yet.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 16, 2016, 10:38:24 pm
@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 (https://github.com/scp-fs2open/wxLauncher/pull/150) 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).
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 17, 2016, 11:21:50 am
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 18, 2016, 12:10:16 am
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 (http://www.hard-light.net/forums/index.php?topic=89162.msg1829671#msg1829671) to fix some crashes I was getting on OS X on wxL exit, as well as the patch in this post (http://www.hard-light.net/forums/index.php?topic=89162.msg1829727#msg1829727) 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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 18, 2016, 12:06:41 pm
@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 (http://www.hard-light.net/forums/index.php?topic=89162.msg1829671#msg1829671) to fix some crashes I was getting on OS X on wxL exit, as well as the patch in this post (http://www.hard-light.net/forums/index.php?topic=89162.msg1829727#msg1829727) 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 (https://github.com/scp-fs2open/wxLauncher/blob/master/cmake/wxLauncherInstaller.cmake#L74)
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 18, 2016, 12:29:32 pm
Patches have been updated on the fix/osxsdl.  Note I did rebase that branch on the updated master.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 19, 2016, 02:01:36 am
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? :mad: ) 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)) {
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 20, 2016, 01:52:53 am
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 21, 2016, 01:03:48 am
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. :sigh: 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
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 21, 2016, 08:09:08 am
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 21, 2016, 08:50:41 am
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. :sigh: 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 (https://github.com/scp-fs2open/fs2open.github.com/pull/955/files).  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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 23, 2016, 03:40:16 am
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 24, 2016, 12:27:58 am
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 (https://travis-ci.org/scp-fs2open/wxLauncher/jobs/162376035).
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 24, 2016, 01:05:21 am
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 (https://travis-ci.org/scp-fs2open/wxLauncher/jobs/162376035).
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 24, 2016, 10:51:11 am
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 (https://travis-ci.org/scp-fs2open/wxLauncher/jobs/162376035).
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 24, 2016, 11:27:47 am
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 (https://github.com/travis-ci/travis-ci/issues/6627).  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 (https://travis-ci.org/scp-fs2open/wxLauncher/jobs/162445702).  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 (https://wiki.libsdl.org/SDL_GetPrefPath) which is new in SDL 2.0.1 !?
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 25, 2016, 02:17:48 am
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 :banghead: 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 (https://github.com/travis-ci/travis-ci/issues/6627).  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 (https://travis-ci.org/scp-fs2open/wxLauncher/jobs/162445702).  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 (https://wiki.libsdl.org/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".
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 25, 2016, 09:52:08 am
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.
It depends on compiler building the files.  For linux it bails on the first error.  Visual Studio by default will not and will just build everything anyway.

Also I noticed that the GitHub online version of ReadMe.md leaves out anything I put in angle brackets :banghead: 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.
That will work.  You can alternatively put the entire path in backticks (which will stop markdown from treating the angle brackets as HTML) so that it will also get a fixed width font.  Or you can use the HTML entities
Code: [Select]
&lt; &gt;

I'm not sure what that pull request would look like. Can you explain how to do it?
In bullet form:
I have linked more detailed explanations of the terms.

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.
Variations of this:
Code: [Select]
⚠️  /usr/local/include/wx-3.0/wx/any.h:336:5: expression with side effects will be evaluated despite being used as an operand to 'typeid' [-Wpotentially-evaluated-expression]
    WX_DECLARE_ANY_VALUE_TYPE(wxAnyValueTypeImpl<T>)
    ^
I am not really sure there is much we can do as it all appears to be from wxWidgets anyway.

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".
CMake has string compare tools (https://cmake.org/cmake/help/v3.0/command/string.html).  The other option is to check if a specific header file exists in the found library.

The third option is to add the binary bits of the framework to the 3rdparty directory of the repository like we have done for windows and use the headers included in the repository.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 25, 2016, 10:33:55 am
Since sdl provides the framework we need, couldn't the script download that instead of using homebrew?  Or we include a frameworks archive for wxlauncher like fs2 does?  Not saying that's the best way but it has worked since it is what we link into the bundle anyway.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 25, 2016, 11:58:33 am
That would work as well.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 25, 2016, 07:35:47 pm
Ok, fork created. Thanks for your help.

I'm adding SDL2.framework.tgz (just a tarball of SDL2.framework from the FSO source tree) to 3rdparty/SDL2-2_0_3/lib/mac/SDL2.framework.tgz

Since the contents of SDL2.framework/Headers don't seem to be identical to the contents of 3rdparty/SDL2-2_0_3/include/ (for one thing, the latter has more files), then should I make a new folder say 3rdparty/SDL2-2_0_3/include_mac with a copy of the contents of SDL2.framework/Headers?


Or actually maybe the directory structure in the wxL repo should be
3rdparty/SDL2-2_0_3/mac/lib/SDL2.framework.tgz
3rdparty/SDL2-2_0_3/mac/include/ # framework's headers would go here


Also, I didn't realize that the Travis CI scripts were in the repo's ci folder. Hmm, I'm really not sure how to modify them to fit the ReadMe, both since I'm not sure how the scripts should work and also my shell scripting is a bit limited/rusty. Perhaps someone can help?


Here's what I need:

- Download wxWidgets 3.0.2 source
https://github.com/wxWidgets/wxWidgets/releases/download/v3.0.2/wxWidgets-3.0.2.tar.bz2

- Build wxWidgets:
Code: [Select]
tar -xf wxWidgets-3.0.2.tar.bz2
cd wxWidgets-3.0.2
mkdir build-debug # assuming we're doing debug only build
cd build-debug
../configure --enable-stl --enable-unicode --enable-debug --disable-shared --with-macosx-version-min=10.9 CC=clang CXX=clang++ CXXFLAGS="-stdlib=libc++ -std=c++11" OBJCXXFLAGS="-stdlib=libc++ -std=c++11" LDFLAGS=-stdlib=libc++
make -j4 # or whatever the right number should be for the -j option

- Get Python 3 if not installed, or at least get things working with Python 2, which I couldn't figure out how to do without modifying the scripts (commenting outlines about builtins). Although to be faithful to following the ReadMe.md for OS X, maybe Travis should use Python 3 even if Python 2 can work?

- Get Markdown for Python and install with pip (CI scripts seem to do this for Python 2 if  that setup is already working?)

- Untar the SDL2.framework.tgz in 3rdparty/SDL2-2_0_3/lib/mac/ and copy it to ~/Library/Frameworks/, creating the Frameworks folder if it doesn't already exist

- Get CMake 3 if not installed

- [Don't need OpenAL Soft for Travis CI build I don't think, APple's built in OpenAL should be good enough and it's what FSO uses anyway]

- Clone wxl repo

- Then configure wxL with CMake:
Code: [Select]
cd wxLauncher # assuming that's the name of the repo
mkdir build
cd build
cmake -G Xcode -DwxWidgets_CONFIG_EXECUTABLE=/path/to/wxWidgets/Build/Folder/wx-config -DPYTHON_EXECUTABLE=/path/to/python3 -DUSE_OPENAL=1 ../

Important points:
= point wxWidgets_CONFIG_EXECUTABLE to point to wherever wxWidgets 3.0.2 was built
= The ReadMe says to manuallly set PYTHON_EXECUTABLE to point to Python 3, since by default CMake finds the pre-installed Python 2, although if using 2 then maybe manually specifying PYTHON_EXECUTABLE isn't necessary.
= Not sure if manually setting USE_OPENAL to 1 is necessary but I figured it couldn't hurt.

Assuming CMake succeeds, build wxL with
Code: [Select]
xcodebuild -configuration Debug # assuming Debug is what we're building

I think that should be it.


Since OS X doesn't include the wget tool, I think it's possible to download files using the curl command line tool, which does AFAIK come with OS X?


While I'm waiting to get help with the CI scripts, I'll work on updating CMakeLists.txt and the ReadMe.md.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 25, 2016, 07:55:06 pm
The fso tree has sdl 2.0.4, but it is identical to the official sdl release, so I always just get it from them directly.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 27, 2016, 12:56:45 pm
Something I was wondering the other day:  If we are linking against SDL for joystick detection, how did joystick detection work with old SDL builds, in the last official wxLauncher release?  It appears the old bundle included the SDL.framework file, just like we do with FS2.  Makes me surprised this has become so difficult to handle the change to SDL2 then.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 27, 2016, 04:14:18 pm
I would assume it is a combination of the previous official release of wxL was using SDL 1.4 and the previous release was a year ago
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 28, 2016, 11:10:50 am
After putting the SDL2.framework in my ~/Libraries/Frameworks folder, compiling wxWidgets with the patches from Homebrew, and then using those for the build process, I have a wxLauncher that doesn't seem to have any external dependencies.  But it can't find any FS2 builds in my FS2 folder now.

Screenshot (https://www.dropbox.com/s/k1vkunixexygikr/Screenshot%202016-09-28%2011.06.49.png?dl=0)
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 28, 2016, 12:26:06 pm
Please make a debug build -DCMAKE_BUILD_TYPE=Debug and post the log and a screenshot of the contents of the selected root.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 28, 2016, 12:28:26 pm
I've already narrowed it down I think.  0.10.x would find builds starting with FS2_ and fs2_ but now the glob seems to be ignoring uppercase builds.  At the moment I only had older builds, nothing matching the newer convention.  Was trying to see if there's an easy way to make the glob case insensitive for Macs, I think that would fix it.  I put a new build that starts with fs2_ in the folder and it shows up now.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 28, 2016, 05:13:14 pm
Uploaded a wxWidgets for Mac build here (http://scp.indiegames.us/temp/wxmac-3.0.2-static-unicode-stl-c11.tgz).  I applied the patches in the Homebrew wxmac brew formula (https://github.com/Homebrew/homebrew-core/blob/master/Formula/wxmac.rb) to fix compilation issues I ran into.  I believe those were related to targeting OS X 10.9.  Applying the patches corrected compilation on Xcode 8.0 and allowed me to finish a set of static libraries with no non-standard OS X dependencies.  This library could be used similarly to the ones m|m has been uploading to bintray for FS2's CMake process.  It could be downloaded and tested now, by simply extracting it and pointing the wx-config argument for wxLauncher to the bin folder within the extracted archive folder, where the wx-config binary lives.  Between being able to use the stock SDL2 framework (which could potentially also be downloaded by CMake automatically or placed in the repository), and this precompiled library, I think we could really simplify the wxLauncher process going forward for OS X developers, as one can now make a wxLauncher build on a new environment without compiling anything but wxLauncher.

I'll also add that python2 worked fine for me.  I didn't need to mess with pip3/python3 to get the necessary compilation dependencies installed.  I don't know if macOS 10.12 (Sierra) will default me to python3 when I upgrade soon though.

I haven't been able to come up with a good solution for the issue of it not finding my older named apps.  I am not sure if the old wxLauncher used a non-unicode wxWidgets, and maybe the unicode version is treating the filespec in a case-sensitive manner now?  If so, a new solution would have to be devised for macs to find either FS2 or fs2, such as looking for both and merging the result set.  This would really mess up the current pattern though.  I'd almost say we could just ask users to rename older mac binaries to lowercase if another solution isn't obvious to anyone.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 28, 2016, 09:14:30 pm
I still think that a debug log will be helpful.  The code is not case sensitive on any platform.  I checked wxWidgets 3.1 (because I have the mac port of it here) and it makes a point of converting everything to lowercase.

Specifically which FS2 binaries do you have?
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 28, 2016, 09:25:38 pm
I'll see if I can get one tomorrow.  The 3.7.4 official release for instance, it would not find.  Only a lowercase build I had just made and copied into my FS2 folder.  I had found other people with this issue on their forum but not with this specific function.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 29, 2016, 01:04:11 am
I am able to reproduce chief's issue on my MacBook Pro running El Capitan. "FS2_Open 3.7.4.app" does not appear in the list of builds but "fs2_open 3.7.4.app" does.

I am attending a gaymer convention this weekend and may not have time to debug this until next week.


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.

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 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.

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.

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.

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.

wxL releases for OS X have always been Unicode.

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.

As for why 0.12.0 on OS X has been so hard, it's a mix of factors
- SDL 1 to SDL 2 (sizable jump)
- wxWidgets 2.8 to 3.0 (big jump)
- CMake 2.8 to CMake 3.6 (another big jump)
- new C++11 requirement resulting from switch to wxWidgets 3
- plus whatever changes have been piled onto the launcher in the last year, including changes to the CMake build setup,
and that OS X support for wxL has been kind of neglected as of late so there was a good bit of catchup just from that. The old wxL build instructions were ancient. Not pointing fingers, mind you, just stating the facts.

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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 29, 2016, 08:22:45 am
As I said before, I have no problem supporting only one build environment for OSX.

Python 2 works now because I removed the code that depended on the Python future module that was temporally a dependency of the prerelease 0.12.0.

The content of the fs2 .app directories is different between the current master and the 3.7.4 release. So the debug log from wxL should be helpful in understanding what is going wrong.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 29, 2016, 08:32:00 am
I'll look but I already compiled a build with debugging lines around the call that does the glob and it does not return the uppercase app folder names in that array.  Will be at work shortly.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 29, 2016, 09:35:40 am
In that case, try a * glob and see what you get for bytes in the filenames.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 29, 2016, 09:46:10 am
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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 29, 2016, 10:17:51 am
Here's the log, I'll mess with the glob in a bit but figured I'd get this now while I'm tweaking the wx prebuilt lib.  By default it doesn't work in a location other than where it was installed but I think I can get a relative path in its config file and make it work, since we're statically linking.

Code: [Select]
16273151406:DEBUG:Created news map entry for source hlp
16273151406:DEBUG:  Opening /Users/cliffgordon/Library/Application Support/wxlauncher/pro00000.ini
16273151406:DEBUG:  Opened profile named: Default
16273151406:DEBUG:  Opening /Users/cliffgordon/Library/Application Support/wxlauncher/pro00001.ini
16273151406:DEBUG:  Opened profile named: FS2
16273151406:DEBUG:  Opening /Users/cliffgordon/Library/Application Support/wxlauncher/pro00002.ini
16273151406:DEBUG:  Opened profile named: FotG
16273151406:DEBUG:  Opening /Users/cliffgordon/Library/Application Support/wxlauncher/pro00003.ini
16273151406:DEBUG:  Opened profile named: Diaspora
16273151406:DEBUG: Searching for profile: FS2
16273151406:DEBUG: Making 'FS2' the application profile
16273151406:DEBUG:Generating current profile changed event
16273151406:DEBUG: Profile Manager is set up
16273151406:DEBUG:Profile 'FS2' saved to '/Users/cliffgordon/Library/Application Support/wxlauncher/pro00001.ini'
16273151406:STSBR:Profile 'FS2' saved
16273151406:DEBUG:Current config saved.
16273151406:STSBR:Now autosaving profiles.
16273151406:DEBUG:ModsPage is at 0x7fc138e77430.
16273151406:DEBUG:I found 2 .ini files:
16273151406:DEBUG:Inserting '(No mod)'
16273151406:DEBUG: Using defaults for TC.
16273151406:DEBUG:Starting to parse mod.ini's...
16273151406:DEBUG:  Parsing /Applications/Freespace2/bpcomplete/mod.ini
16273151406:DEBUG:   Opened ok
16273151406:DEBUG:   Mod fancy name is: Blue Planet Complete;
16273151406:DEBUG:   Mod short name is: bpcomplete
16273151406:DEBUG:  Parsing /Applications/Freespace2/MediaVPs_2014/mod.ini
16273151406:DEBUG:   Opened ok
16273151406:DEBUG:   Mod fancy name is: MediaVPs 2014;
16273151406:DEBUG:   Mod short name is: MediaVPs_2014
16273151406:DEBUG:Transforming mod.ini's
16273151406:DEBUG: (No mod)
16273151406:DEBUG:  /launcher/modname:'Not Specified'
16273151406:DEBUG:  /launcher/image255x112:'Not Specified'
16273151406:DEBUG:  /launcher/image182x80:'Not Specified'
16273151406:DEBUG:  /launcher/infotext:'Not Specified'
16273151406:DEBUG:  /launcher/author:'Not Specified'
16273151406:DEBUG:  /launcher/notes:'Not Specified'
16273151406:DEBUG:  /launcher/website:'Not Specified'
16273151406:DEBUG:  /launcher/forum:'Not Specified'
16273151406:DEBUG:  /launcher/bugs:'Not Specified'
16273151406:DEBUG:  /launcher/support:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/name:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273151406:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273151406:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273151406:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273151406:DEBUG:  /multimod/primarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondrylist:'Not Specified'
16273151406:DEBUG:  Does Not Contain A skin Section.
16273151406:DEBUG: bpcomplete
16273151406:DEBUG:  /launcher/modname:'Blue Planet Complete'
16273151406:DEBUG:  /launcher/image255x112:'bplogo.bmp'
16273151406:DEBUG:  /launcher/image182x80:'Not Specified'
16273151406:DEBUG:  /launcher/infotext:'The FreeSpace story continues. 18 years after the events of FreeSpace 2, the Security Council deploys the elite 14th Battlegroup to re-establish contact with Earth.'
16273151406:DEBUG:  /launcher/author:'Not Specified'
16273151406:DEBUG:  /launcher/notes:'Not Specified'
16273151406:DEBUG:  /launcher/website:'http://blueplanet.hard-light.net'
16273151406:DEBUG:  /launcher/forum:'http://www.hard-light.net/forums/index.php/board,169.0.html'
16273151406:DEBUG:  /launcher/bugs:'Not Specified'
16273151406:DEBUG:  /launcher/support:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/name:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273151406:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273151406:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273151406:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273151406:DEBUG:  /multimod/primarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondarylist:'mediavps_2014'
16273151406:DEBUG: MediaVPs_2014
16273151406:DEBUG:  /launcher/modname:'MediaVPs 2014'
16273151406:DEBUG:  /launcher/image255x112:'FSU-MVP.bmp'
16273151406:DEBUG:  /launcher/image182x80:'FSU-MVP_small.bmp'
16273151406:DEBUG:  /launcher/infotext:'Freespace II - SVN MediaVPs'
16273151406:DEBUG:  /launcher/author:'Not Specified'
16273151406:DEBUG:  /launcher/notes:'Not Specified'
16273151406:DEBUG:  /launcher/website:'http://www.hard-light.net/'
16273151406:DEBUG:  /launcher/forum:'http://www.hard-light.net/forums'
16273151406:DEBUG:  /launcher/bugs:'Not Specified'
16273151406:DEBUG:  /launcher/support:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/name:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273151406:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273151406:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273151406:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273151406:DEBUG:  /multimod/primarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondrylist:'Not Specified'
16273151406:DEBUG:New modline is
16273151406:DEBUG:Generating EVT_TC_ACTIVE_MOD_CHANGED event
16273151406:DEBUG:BasicSettingsPage is at 0x7fc138d5f940.
16273151406:DEBUG:TCManager is at 0x7fc138d60530.
16273151406:DEBUG:Enumerating graphics modes with SDL
16273151406:DEBUG: found aspect ratio 16:10
16273151406:DEBUG: found aspect ratio 3:2
16273151406:DEBUG: found aspect ratio 4:3
16273151406:DEBUG:no resolution found in map, attempting to use profile value
16273151406:DEBUG:Wrote resolution 1280x800 for mod (No mod)
16273151406:DEBUG:Generating EVT_RESOLUTION_MAP_CHANGED event
16273151406:DEBUG:lighting preset Off selected
16273151406:DEBUG:Generating EVT_CMD_LINE_CHANGED event
16273151406:DEBUG:AdvSettingsPage is at 0x7fc138c87b40.
16273151406:DEBUG:BottomButtons is at 0x7fc138c9e410.
16273151406:STSBR:MainWindow is complete
16273151406:DEBUG:Generating EVT_TC_CHANGED event
16273151406:DEBUG: Sent EVT_TC_CHANGED event to 0x7fc138e77430
16273151406:DEBUG: Sent EVT_TC_CHANGED event to 0x7fc138d5f940
16273151406:DEBUG: Sent EVT_TC_CHANGED event to 0x7fc138c9e410
16273151406:STSBR:Ready.
16273151406:DEBUG:I found 2 .ini files:
16273151406:DEBUG:Inserting '(No mod)'
16273151406:DEBUG: Using defaults for TC.
16273151406:DEBUG:Starting to parse mod.ini's...
16273151406:DEBUG:  Parsing /Applications/Freespace2/bpcomplete/mod.ini
16273151406:DEBUG:   Opened ok
16273151406:DEBUG:   Mod fancy name is: Blue Planet Complete;
16273151406:DEBUG:   Mod short name is: bpcomplete
16273151406:DEBUG:  Parsing /Applications/Freespace2/MediaVPs_2014/mod.ini
16273151406:DEBUG:   Opened ok
16273151406:DEBUG:   Mod fancy name is: MediaVPs 2014;
16273151406:DEBUG:   Mod short name is: MediaVPs_2014
16273151406:DEBUG:Transforming mod.ini's
16273151406:DEBUG: (No mod)
16273151406:DEBUG:  /launcher/modname:'Not Specified'
16273151406:DEBUG:  /launcher/image255x112:'Not Specified'
16273151406:DEBUG:  /launcher/image182x80:'Not Specified'
16273151406:DEBUG:  /launcher/infotext:'Not Specified'
16273151406:DEBUG:  /launcher/author:'Not Specified'
16273151406:DEBUG:  /launcher/notes:'Not Specified'
16273151406:DEBUG:  /launcher/website:'Not Specified'
16273151406:DEBUG:  /launcher/forum:'Not Specified'
16273151406:DEBUG:  /launcher/bugs:'Not Specified'
16273151406:DEBUG:  /launcher/support:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/name:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273151406:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273151406:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273151406:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273151406:DEBUG:  /multimod/primarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondrylist:'Not Specified'
16273151406:DEBUG:  Does Not Contain A skin Section.
16273151406:DEBUG: bpcomplete
16273151406:DEBUG:  /launcher/modname:'Blue Planet Complete'
16273151406:DEBUG:  /launcher/image255x112:'bplogo.bmp'
16273151406:DEBUG:  /launcher/image182x80:'Not Specified'
16273151406:DEBUG:  /launcher/infotext:'The FreeSpace story continues. 18 years after the events of FreeSpace 2, the Security Council deploys the elite 14th Battlegroup to re-establish contact with Earth.'
16273151406:DEBUG:  /launcher/author:'Not Specified'
16273151406:DEBUG:  /launcher/notes:'Not Specified'
16273151406:DEBUG:  /launcher/website:'http://blueplanet.hard-light.net'
16273151406:DEBUG:  /launcher/forum:'http://www.hard-light.net/forums/index.php/board,169.0.html'
16273151406:DEBUG:  /launcher/bugs:'Not Specified'
16273151406:DEBUG:  /launcher/support:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/name:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273151406:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273151406:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273151406:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273151406:DEBUG:  /multimod/primarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondarylist:'mediavps_2014'
16273151406:DEBUG: MediaVPs_2014
16273151406:DEBUG:  /launcher/modname:'MediaVPs 2014'
16273151406:DEBUG:  /launcher/image255x112:'FSU-MVP.bmp'
16273151406:DEBUG:  /launcher/image182x80:'FSU-MVP_small.bmp'
16273151406:DEBUG:  /launcher/infotext:'Freespace II - SVN MediaVPs'
16273151406:DEBUG:  /launcher/author:'Not Specified'
16273151406:DEBUG:  /launcher/notes:'Not Specified'
16273151406:DEBUG:  /launcher/website:'http://www.hard-light.net/'
16273151406:DEBUG:  /launcher/forum:'http://www.hard-light.net/forums'
16273151406:DEBUG:  /launcher/bugs:'Not Specified'
16273151406:DEBUG:  /launcher/support:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/name:'Not Specified'
16273151406:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273151406:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273151406:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273151406:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273151406:DEBUG:  /multimod/primarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondarylist:'Not Specified'
16273151406:DEBUG:  /multimod/secondrylist:'Not Specified'
16273151406:DEBUG:New modline is
16273151406:DEBUG:Generating EVT_TC_ACTIVE_MOD_CHANGED event
16273151406:DEBUG: Sent EVT_TC_ACTIVE_MOD_CHANGED event to 0x7fc138d5f940
16273151406:DEBUG: Sent EVT_TC_ACTIVE_MOD_CHANGED event to 0x7fc138c88780
16273151406:DEBUG: Sent EVT_TC_ACTIVE_MOD_CHANGED event to 0x7fc138c87b40
16273151406:DEBUG: Sent EVT_TC_ACTIVE_MOD_CHANGED event to 0x7fc138c9e410
16273151406:DEBUG:Found executable: fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG
16273151406:DEBUG:Making version struct for the executable 'fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG'
16273151406:DEBUG:The current root folder is valid.
16273151406:DEBUG:Generating EVT_TC_BINARY_CHANGED event
16273151406:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x7fc138c39ed0
16273151406:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x7fc138d5f940
16273151406:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x7fc138c9e410
16273151406:DEBUG:Enumerating graphics modes with SDL
16273151406:DEBUG: found aspect ratio 16:10
16273151406:DEBUG: found aspect ratio 3:2
16273151406:DEBUG: found aspect ratio 4:3
16273151406:DEBUG:Wrote resolution 1280x800 for mod (No mod)
16273151406:DEBUG:Generating EVT_RESOLUTION_MAP_CHANGED event
16273151406:DEBUG: Sent EVT_RESOLUTION_MAP_CHANGED event to 0x7fc138c9e410
16273151406:DEBUG:The current profile's listed FSO executable 'fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG' is valid.
16273151406:DEBUG:current flag file processing status: 1
16273151406:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16273151406:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7fc138c4dbd0
16273151406:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7fc138d5f940
16273151406:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7fc138c87b40
16273151406:DEBUG:Generating EVT_PROXY_RESET event
16273151406:DEBUG: Sent EVT_PROXY_RESET event to 0x7fc138c87b40
16273151406:DEBUG:Initializing flag file processing.
16273151406:DEBUG:exeName: fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG
16273151406:DEBUG:exeFilename: /Applications/Freespace2/fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG
16273151406:DEBUG: Called FS2 Open with command line '/Applications/Freespace2/fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG -get_flags'.
16273151406:DEBUG:wxMacLaunch Bad bundle: /Applications/Freespace2/fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG
16273151406:DEBUG:current flag file processing status: 7
16273151406:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16273151406:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7fc138c4dbd0
16273151406:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7fc138d5f940
16273151406:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7fc138c87b40
16273151407:DEBUG: FS2 Open returned 1 when polled for the flags
16273151407:DEBUG: Searching for flag file at /Users/cliffgordon/Library/Application Support/wxlauncher/temp_flag_folder/flags.lch ... Located
16273151407:DEBUG:Reading flag file /Users/cliffgordon/Library/Application Support/wxlauncher/temp_flag_folder/flags.lch.
16273151407:DEBUG: easy_flag_size: 32, 4; flag_size: 344, 4; num_easy_flags: 5, 4; num_flags: 86, 4
16273151407:DEBUG:current flag file processing status: 0
16273151407:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16273151407:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7fc138c4dbd0
16273151407:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7fc138d5f940
16273151407:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7fc138c87b40
16273151409:DEBUG:news loaded from http://www.audiozone.ro/hl/ with type text/html
16273151409:DEBUG:Generating EVT_PROXY_FLAG_DATA_READY event
16273151409:DEBUG: Sent EVT_PROXY_FLAG_DATA_READY event to 0x7fc138c88780
16273151409:DEBUG: Sent EVT_PROXY_FLAG_DATA_READY event to 0x7fc138c87b40
16273151410:DEBUG:System default OpenAL device: Built-in Output
16273151410:DEBUG:System default OpenAL capture device: Built-in Microphone
16273151410:DEBUG:Playback device 'Built-in Output' does not support EFX. Hiding Enable EFX checkbox.
16273151410:DEBUG:min audio new sound sizer width: 257
16273151410:DEBUG:max device combo length: 215
16273151410:DEBUG:Enumerating graphics modes with SDL
16273151410:DEBUG: found aspect ratio 16:10
16273151410:DEBUG: found aspect ratio 3:2
16273151410:DEBUG: found aspect ratio 4:3
16273151410:DEBUG:Wrote resolution 1280x800 for mod (No mod)
16273151410:DEBUG:Generating EVT_RESOLUTION_MAP_CHANGED event
16273151410:DEBUG: Sent EVT_RESOLUTION_MAP_CHANGED event to 0x7fc138c9e410
16273151410:DEBUG:Generating EVT_FLAG_LIST_BOX_READY event
16273151410:DEBUG: Sent EVT_FLAG_LIST_BOX_READY event to 0x7fc138c87b40
16273151410:DEBUG:Generating EVT_CUSTOM_FLAGS_CHANGED event
16273151410:DEBUG: Sent EVT_CUSTOM_FLAGS_CHANGED event to 0x7fc138c87b40
16273151410:DEBUG:Generating EVT_CMD_LINE_CHANGED event
16273151410:DEBUG: Sent EVT_CMD_LINE_CHANGED event to 0x7fc138c87b40
16273151410:DEBUG:lighting preset Off selected
16273151410:DEBUG:Generating EVT_CMD_LINE_CHANGED event
16273151410:DEBUG: Sent EVT_CMD_LINE_CHANGED event to 0x7fc138c87b40
16273151413:DEBUG:FlagListManager::DeInitialize(): contents of handler list:
16273151413:DEBUG: handler at 0x7fc138d5f940
16273151413:DEBUG: handler at 0x7fc138c87b40
16273151413:DEBUG:SkinSystem::DeInitialize(): contents of handler list:
16273151413:DEBUG: handler at 0x7fc138c43320
16273151413:DEBUG: handler at 0x7fc138d56ef0
16273151413:DEBUG: handler at 0x7fc138e5ce60
16273151413:DEBUG: handler at 0x7fc138e5d880
16273151413:DEBUG: handler at 0x7fc138e77430

Log closed.

FS2 folder:

Code: [Select]
cliffgordon@cliffmbp:/Applications/Freespace2  $ ls -al
total 3091472
drwxr-xr-x  29 cliffgordon  admin        986 Sep 29 10:17 ./
drwxrwxr-x+ 77 root         admin       2618 Sep 28 11:07 ../
-rw-r--r--   1 cliffgordon  admin   23186780 Sep 26 16:30 Archive.zip
-rwxrwxrwx   1 cliffgordon  admin  263640995 Oct 31  2013 FS2OGGcutscenepack.vp*
drwxr-xr-x@  3 cliffgordon  admin        102 Apr 23  2015 FS2_Open 3.7.2 (debug).app/
drwxr-xr-x@  3 cliffgordon  admin        102 Apr 23  2015 FS2_Open 3.7.2.app/
drwxr-xr-x   3 cliffgordon  admin        102 Jul  4 12:26 FS2_Open 3.7.4 (debug).app/
drwxr-xr-x   3 cliffgordon  admin        102 Jul  4 12:25 FS2_Open 3.7.4.app/
drwxr-xr-x   3 cliffgordon  staff        102 Jul 21 10:08 FS2_Open 3.7.5 20160721 c3c66c9 (debug).app/
drwxr-xr-x   3 cliffgordon  staff        102 Jul 21 10:09 FS2_Open 3.7.5 20160721 c3c66c9.app/
drwxr-xr-x   3 cliffgordon  admin        102 Jul  6 00:32 FS2_Open Ant9 20160705 (debug).app/
drwxr-xr-x   3 cliffgordon  admin        102 Jul  6 00:39 FS2_Open Ant9 20160705.app/
drwxr-xr-x   3 cliffgordon  admin        102 Jul  6 10:56 FS2_Open Ant9 SDL204 (debug).app/
drwxr-xr-x   3 cliffgordon  admin        102 Jul  6 10:56 FS2_Open Ant9 SDL204.app/
drwxr-xr-x@ 15 cliffgordon  staff        510 Jul  6 10:47 MediaVPs_2014/
drwxr-xr-x  19 cliffgordon  staff        646 Jul  6 11:01 bpcomplete/
drwxr-xr-x   3 cliffgordon  admin        102 Jul  6 00:15 data/
drwxr-xr-x   3 cliffgordon  staff        102 Sep 26 16:19 fs2_open_3_7_5_x64-DEBUG.app/
-rwxrwxrwx   1 cliffgordon  admin    5774914 Nov  1  2013 multi-mission-pack.vp*
-rwxrwxrwx   1 cliffgordon  admin   23678622 Nov  1  2013 multi-voice-pack.vp*
-rwxrwxrwx   1 cliffgordon  admin    6404494 Nov 17  1999 root_fs2.vp*
-rwxrwxrwx   1 cliffgordon  admin  123125814 Sep 15  1999 smarty_fs2.vp*
-rwxrwxrwx   1 cliffgordon  admin  260563452 Sep 15  1999 sparky_fs2.vp*
-rwxrwxrwx   1 cliffgordon  admin  265242014 Sep 15  1999 sparky_hi_fs2.vp*
-rwxrwxrwx   1 cliffgordon  admin  173166260 Sep 15  1999 stu_fs2.vp*
-rwxrwxrwx   1 cliffgordon  admin  195887233 Sep 15  1999 tango1_fs2.vp*
-rwxrwxrwx   1 cliffgordon  admin   72778161 Sep 15  1999 tango2_fs2.vp*
-rwxrwxrwx   1 cliffgordon  admin   50497261 Sep 15  1999 tango3_fs2.vp*
-rwxrwxrwx   1 cliffgordon  admin  118858128 Sep 15  1999 warble_fs2.vp*
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 29, 2016, 10:35:20 am
Guess my precompiled binary doesn't work when not in the location I installed it after all.  Tried moving it to my user folder and point to it there, no such luck.  I can screw with the wx-config file and change the prefix to a relative path which fixes compiling (helps it find the headers still), but breaks linking (tries using relative paths with all the -l values that don't work).  So, I still think it could work, but CMake would have to use regex or something to replace the input_option_prefix line in wx-config with a full path including wherever the user is compiling wxLauncher.  Or, it would need to extract the library outside of the build folder, to some common location like a temp folder or something, that we could program in advance.  Neither quite sounds ideal, but I can modify the prebuilt lib to expect to live in /tmp/wxmac and compile successfully already.  All that would need to be done is modifying the CMake script to download the archive and extract it to /tmp/ if a system wx install is not found.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on September 29, 2016, 10:42:08 am
If I switch the glob to "FS2_*.app" I get the opposite result as I expected, the new app found in the last log is not found, but all the older ones are.

Code: [Select]
16273154010:DEBUG:Created news map entry for source hlp
16273154010:DEBUG:  Opening /Users/cliffgordon/Library/Application Support/wxlauncher/pro00000.ini
16273154010:DEBUG:  Opened profile named: Default
16273154010:DEBUG:  Opening /Users/cliffgordon/Library/Application Support/wxlauncher/pro00001.ini
16273154010:DEBUG:  Opened profile named: FS2
16273154010:DEBUG:  Opening /Users/cliffgordon/Library/Application Support/wxlauncher/pro00002.ini
16273154010:DEBUG:  Opened profile named: FotG
16273154010:DEBUG:  Opening /Users/cliffgordon/Library/Application Support/wxlauncher/pro00003.ini
16273154010:DEBUG:  Opened profile named: Diaspora
16273154010:DEBUG: Searching for profile: FS2
16273154010:DEBUG: Making 'FS2' the application profile
16273154010:DEBUG:Generating current profile changed event
16273154010:DEBUG: Profile Manager is set up
16273154010:DEBUG:Profile 'FS2' saved to '/Users/cliffgordon/Library/Application Support/wxlauncher/pro00001.ini'
16273154010:STSBR:Profile 'FS2' saved
16273154010:DEBUG:Current config saved.
16273154010:STSBR:Now autosaving profiles.
16273154010:DEBUG:ModsPage is at 0x7f97ca68dae0.
16273154010:DEBUG:I found 2 .ini files:
16273154010:DEBUG:Inserting '(No mod)'
16273154010:DEBUG: Using defaults for TC.
16273154010:DEBUG:Starting to parse mod.ini's...
16273154010:DEBUG:  Parsing /Applications/Freespace2/bpcomplete/mod.ini
16273154010:DEBUG:   Opened ok
16273154010:DEBUG:   Mod fancy name is: Blue Planet Complete;
16273154010:DEBUG:   Mod short name is: bpcomplete
16273154010:DEBUG:  Parsing /Applications/Freespace2/MediaVPs_2014/mod.ini
16273154010:DEBUG:   Opened ok
16273154010:DEBUG:   Mod fancy name is: MediaVPs 2014;
16273154010:DEBUG:   Mod short name is: MediaVPs_2014
16273154010:DEBUG:Transforming mod.ini's
16273154010:DEBUG: (No mod)
16273154010:DEBUG:  /launcher/modname:'Not Specified'
16273154010:DEBUG:  /launcher/image255x112:'Not Specified'
16273154010:DEBUG:  /launcher/image182x80:'Not Specified'
16273154010:DEBUG:  /launcher/infotext:'Not Specified'
16273154010:DEBUG:  /launcher/author:'Not Specified'
16273154010:DEBUG:  /launcher/notes:'Not Specified'
16273154010:DEBUG:  /launcher/website:'Not Specified'
16273154010:DEBUG:  /launcher/forum:'Not Specified'
16273154010:DEBUG:  /launcher/bugs:'Not Specified'
16273154010:DEBUG:  /launcher/support:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/name:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273154010:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273154010:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273154010:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273154010:DEBUG:  /multimod/primarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondrylist:'Not Specified'
16273154010:DEBUG:  Does Not Contain A skin Section.
16273154010:DEBUG: bpcomplete
16273154010:DEBUG:  /launcher/modname:'Blue Planet Complete'
16273154010:DEBUG:  /launcher/image255x112:'bplogo.bmp'
16273154010:DEBUG:  /launcher/image182x80:'Not Specified'
16273154010:DEBUG:  /launcher/infotext:'The FreeSpace story continues. 18 years after the events of FreeSpace 2, the Security Council deploys the elite 14th Battlegroup to re-establish contact with Earth.'
16273154010:DEBUG:  /launcher/author:'Not Specified'
16273154010:DEBUG:  /launcher/notes:'Not Specified'
16273154010:DEBUG:  /launcher/website:'http://blueplanet.hard-light.net'
16273154010:DEBUG:  /launcher/forum:'http://www.hard-light.net/forums/index.php/board,169.0.html'
16273154010:DEBUG:  /launcher/bugs:'Not Specified'
16273154010:DEBUG:  /launcher/support:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/name:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273154010:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273154010:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273154010:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273154010:DEBUG:  /multimod/primarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondarylist:'mediavps_2014'
16273154010:DEBUG: MediaVPs_2014
16273154010:DEBUG:  /launcher/modname:'MediaVPs 2014'
16273154010:DEBUG:  /launcher/image255x112:'FSU-MVP.bmp'
16273154010:DEBUG:  /launcher/image182x80:'FSU-MVP_small.bmp'
16273154010:DEBUG:  /launcher/infotext:'Freespace II - SVN MediaVPs'
16273154010:DEBUG:  /launcher/author:'Not Specified'
16273154010:DEBUG:  /launcher/notes:'Not Specified'
16273154010:DEBUG:  /launcher/website:'http://www.hard-light.net/'
16273154010:DEBUG:  /launcher/forum:'http://www.hard-light.net/forums'
16273154010:DEBUG:  /launcher/bugs:'Not Specified'
16273154010:DEBUG:  /launcher/support:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/name:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273154010:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273154010:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273154010:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273154010:DEBUG:  /multimod/primarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondrylist:'Not Specified'
16273154010:DEBUG:New modline is
16273154010:DEBUG:Generating EVT_TC_ACTIVE_MOD_CHANGED event
16273154010:DEBUG:BasicSettingsPage is at 0x7f97ca699770.
16273154010:DEBUG:TCManager is at 0x7f97ca69a1d0.
16273154010:DEBUG:Enumerating graphics modes with SDL
16273154010:DEBUG: found aspect ratio 16:10
16273154010:DEBUG: found aspect ratio 3:2
16273154010:DEBUG: found aspect ratio 4:3
16273154010:DEBUG:no resolution found in map, attempting to use profile value
16273154010:DEBUG:Wrote resolution 1280x800 for mod (No mod)
16273154010:DEBUG:Generating EVT_RESOLUTION_MAP_CHANGED event
16273154010:DEBUG:lighting preset Off selected
16273154010:DEBUG:Generating EVT_CMD_LINE_CHANGED event
16273154010:DEBUG:AdvSettingsPage is at 0x7f97ca7701d0.
16273154010:DEBUG:BottomButtons is at 0x7f97ca45d760.
16273154010:STSBR:MainWindow is complete
16273154010:DEBUG:Generating EVT_TC_CHANGED event
16273154010:DEBUG: Sent EVT_TC_CHANGED event to 0x7f97ca68dae0
16273154010:DEBUG: Sent EVT_TC_CHANGED event to 0x7f97ca699770
16273154010:DEBUG: Sent EVT_TC_CHANGED event to 0x7f97ca45d760
16273154010:STSBR:Ready.
16273154010:DEBUG:I found 2 .ini files:
16273154010:DEBUG:Inserting '(No mod)'
16273154010:DEBUG: Using defaults for TC.
16273154010:DEBUG:Starting to parse mod.ini's...
16273154010:DEBUG:  Parsing /Applications/Freespace2/bpcomplete/mod.ini
16273154010:DEBUG:   Opened ok
16273154010:DEBUG:   Mod fancy name is: Blue Planet Complete;
16273154010:DEBUG:   Mod short name is: bpcomplete
16273154010:DEBUG:  Parsing /Applications/Freespace2/MediaVPs_2014/mod.ini
16273154010:DEBUG:   Opened ok
16273154010:DEBUG:   Mod fancy name is: MediaVPs 2014;
16273154010:DEBUG:   Mod short name is: MediaVPs_2014
16273154010:DEBUG:Transforming mod.ini's
16273154010:DEBUG: (No mod)
16273154010:DEBUG:  /launcher/modname:'Not Specified'
16273154010:DEBUG:  /launcher/image255x112:'Not Specified'
16273154010:DEBUG:  /launcher/image182x80:'Not Specified'
16273154010:DEBUG:  /launcher/infotext:'Not Specified'
16273154010:DEBUG:  /launcher/author:'Not Specified'
16273154010:DEBUG:  /launcher/notes:'Not Specified'
16273154010:DEBUG:  /launcher/website:'Not Specified'
16273154010:DEBUG:  /launcher/forum:'Not Specified'
16273154010:DEBUG:  /launcher/bugs:'Not Specified'
16273154010:DEBUG:  /launcher/support:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/name:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273154010:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273154010:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273154010:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273154010:DEBUG:  /multimod/primarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondrylist:'Not Specified'
16273154010:DEBUG:  Does Not Contain A skin Section.
16273154010:DEBUG: bpcomplete
16273154010:DEBUG:  /launcher/modname:'Blue Planet Complete'
16273154010:DEBUG:  /launcher/image255x112:'bplogo.bmp'
16273154010:DEBUG:  /launcher/image182x80:'Not Specified'
16273154010:DEBUG:  /launcher/infotext:'The FreeSpace story continues. 18 years after the events of FreeSpace 2, the Security Council deploys the elite 14th Battlegroup to re-establish contact with Earth.'
16273154010:DEBUG:  /launcher/author:'Not Specified'
16273154010:DEBUG:  /launcher/notes:'Not Specified'
16273154010:DEBUG:  /launcher/website:'http://blueplanet.hard-light.net'
16273154010:DEBUG:  /launcher/forum:'http://www.hard-light.net/forums/index.php/board,169.0.html'
16273154010:DEBUG:  /launcher/bugs:'Not Specified'
16273154010:DEBUG:  /launcher/support:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/name:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273154010:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273154010:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273154010:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273154010:DEBUG:  /multimod/primarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondarylist:'mediavps_2014'
16273154010:DEBUG: MediaVPs_2014
16273154010:DEBUG:  /launcher/modname:'MediaVPs 2014'
16273154010:DEBUG:  /launcher/image255x112:'FSU-MVP.bmp'
16273154010:DEBUG:  /launcher/image182x80:'FSU-MVP_small.bmp'
16273154010:DEBUG:  /launcher/infotext:'Freespace II - SVN MediaVPs'
16273154010:DEBUG:  /launcher/author:'Not Specified'
16273154010:DEBUG:  /launcher/notes:'Not Specified'
16273154010:DEBUG:  /launcher/website:'http://www.hard-light.net/'
16273154010:DEBUG:  /launcher/forum:'http://www.hard-light.net/forums'
16273154010:DEBUG:  /launcher/bugs:'Not Specified'
16273154010:DEBUG:  /launcher/support:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/name:'Not Specified'
16273154010:DEBUG:  /recommendedlighting/flagset:'Not Specified'
16273154010:DEBUG:Recommended lighting flagset is missing or empty; using defaults.
16273154010:DEBUG:  /extremeforce/forcedflagson:'Not Specified'
16273154010:DEBUG:  /extremeforce/forcedflagsoff:'Not Specified'
16273154010:DEBUG:  /multimod/primarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondarylist:'Not Specified'
16273154010:DEBUG:  /multimod/secondrylist:'Not Specified'
16273154010:DEBUG:New modline is
16273154010:DEBUG:Generating EVT_TC_ACTIVE_MOD_CHANGED event
16273154010:DEBUG: Sent EVT_TC_ACTIVE_MOD_CHANGED event to 0x7f97ca699770
16273154010:DEBUG: Sent EVT_TC_ACTIVE_MOD_CHANGED event to 0x7f97ca770da0
16273154010:DEBUG: Sent EVT_TC_ACTIVE_MOD_CHANGED event to 0x7f97ca7701d0
16273154010:DEBUG: Sent EVT_TC_ACTIVE_MOD_CHANGED event to 0x7f97ca45d760
16273154010:DEBUG:Found executable: FS2_Open 3.7.2 (debug).app/Contents/MacOS/FS2_Open 3.7.2 (debug)
16273154010:DEBUG:Found executable: FS2_Open 3.7.2.app/Contents/MacOS/FS2_Open 3.7.2
16273154010:DEBUG:Found executable: FS2_Open 3.7.4 (debug).app/Contents/MacOS/FS2_Open 3.7.4 (debug)
16273154010:DEBUG:Found executable: FS2_Open 3.7.4.app/Contents/MacOS/FS2_Open 3.7.4
16273154010:DEBUG:Found executable: FS2_Open 3.7.5 20160721 c3c66c9 (debug).app/Contents/MacOS/FS2_Open 3.7.5 20160721 c3c66c9 (debug)
16273154010:DEBUG:Found executable: FS2_Open 3.7.5 20160721 c3c66c9.app/Contents/MacOS/FS2_Open 3.7.5 20160721 c3c66c9
16273154010:DEBUG:Found executable: FS2_Open Ant9 20160705 (debug).app/Contents/MacOS/FS2_Open 3.7.5 (debug)
16273154011:DEBUG:Found executable: FS2_Open Ant9 20160705.app/Contents/MacOS/FS2_Open 3.7.5
16273154011:DEBUG:Found executable: FS2_Open Ant9 SDL204 (debug).app/Contents/MacOS/FS2_Open 3.7.5 (debug)
16273154011:DEBUG:Found executable: FS2_Open Ant9 SDL204.app/Contents/MacOS/FS2_Open 3.7.5
16273154011:DEBUG:Making version struct for the executable 'FS2_Open 3.7.2 (debug).app/Contents/MacOS/FS2_Open 3.7.2 (debug)'
16273154011:DEBUG:Making version struct for the executable 'FS2_Open 3.7.2.app/Contents/MacOS/FS2_Open 3.7.2'
16273154011:DEBUG:Making version struct for the executable 'FS2_Open 3.7.4 (debug).app/Contents/MacOS/FS2_Open 3.7.4 (debug)'
16273154011:DEBUG:Making version struct for the executable 'FS2_Open 3.7.4.app/Contents/MacOS/FS2_Open 3.7.4'
16273154011:DEBUG:Making version struct for the executable 'FS2_Open 3.7.5 20160721 c3c66c9 (debug).app/Contents/MacOS/FS2_Open 3.7.5 20160721 c3c66c9 (debug)'
16273154011:DEBUG:Making version struct for the executable 'FS2_Open 3.7.5 20160721 c3c66c9.app/Contents/MacOS/FS2_Open 3.7.5 20160721 c3c66c9'
16273154011:DEBUG:Making version struct for the executable 'FS2_Open Ant9 20160705 (debug).app/Contents/MacOS/FS2_Open 3.7.5 (debug)'
16273154011:DEBUG:Making version struct for the executable 'FS2_Open Ant9 20160705.app/Contents/MacOS/FS2_Open 3.7.5'
16273154011:DEBUG:Making version struct for the executable 'FS2_Open Ant9 SDL204 (debug).app/Contents/MacOS/FS2_Open 3.7.5 (debug)'
16273154011:DEBUG:Making version struct for the executable 'FS2_Open Ant9 SDL204.app/Contents/MacOS/FS2_Open 3.7.5'
16273154011:DEBUG:BasicSettingsPage::OnTCChanged(): couldn't find selected FSO executable fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG in list of executables
16273154011:DEBUG:The current root folder is valid.
16273154011:DEBUG:Generating EVT_TC_BINARY_CHANGED event
16273154011:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x7f97ca66b830
16273154011:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x7f97ca699770
16273154011:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x7f97ca45d760
16273154011:DEBUG:Enumerating graphics modes with SDL
16273154011:DEBUG: found aspect ratio 16:10
16273154011:DEBUG: found aspect ratio 3:2
16273154011:DEBUG: found aspect ratio 4:3
16273154011:DEBUG:Wrote resolution 1280x800 for mod (No mod)
16273154011:DEBUG:Generating EVT_RESOLUTION_MAP_CHANGED event
16273154011:DEBUG: Sent EVT_RESOLUTION_MAP_CHANGED event to 0x7f97ca45d760
16273154011:DEBUG:The current profile's listed FSO executable 'fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG' is valid.
16273154011:DEBUG:current flag file processing status: 1
16273154011:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16273154011:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7f97ca6625a0
16273154011:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7f97ca699770
16273154011:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7f97ca7701d0
16273154011:DEBUG:Generating EVT_PROXY_RESET event
16273154011:DEBUG: Sent EVT_PROXY_RESET event to 0x7f97ca7701d0
16273154011:DEBUG:Initializing flag file processing.
16273154011:DEBUG:exeName: fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG
16273154011:DEBUG:exeFilename: /Applications/Freespace2/fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG
16273154011:DEBUG: Called FS2 Open with command line '/Applications/Freespace2/fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG -get_flags'.
16273154011:DEBUG:wxMacLaunch Bad bundle: /Applications/Freespace2/fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG
16273154011:DEBUG:current flag file processing status: 7
16273154011:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16273154011:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7f97ca6625a0
16273154011:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7f97ca699770
16273154011:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7f97ca7701d0
16273154011:DEBUG: FS2 Open returned 1 when polled for the flags
16273154011:DEBUG: Searching for flag file at /Users/cliffgordon/Library/Application Support/wxlauncher/temp_flag_folder/flags.lch ... Located
16273154011:DEBUG:Reading flag file /Users/cliffgordon/Library/Application Support/wxlauncher/temp_flag_folder/flags.lch.
16273154011:DEBUG: easy_flag_size: 32, 4; flag_size: 344, 4; num_easy_flags: 5, 4; num_flags: 86, 4
16273154011:DEBUG:current flag file processing status: 0
16273154011:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16273154011:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7f97ca6625a0
16273154011:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7f97ca699770
16273154011:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x7f97ca7701d0
16273154011:DEBUG:Generating EVT_PROXY_FLAG_DATA_READY event
16273154011:DEBUG: Sent EVT_PROXY_FLAG_DATA_READY event to 0x7f97ca770da0
16273154011:DEBUG: Sent EVT_PROXY_FLAG_DATA_READY event to 0x7f97ca7701d0
16273154011:DEBUG:System default OpenAL device: Built-in Output
16273154011:DEBUG:System default OpenAL capture device: Built-in Microphone
16273154011:DEBUG:Playback device 'Built-in Output' does not support EFX. Hiding Enable EFX checkbox.
16273154011:DEBUG:min audio new sound sizer width: 257
16273154011:DEBUG:max device combo length: 215
16273154011:DEBUG:Enumerating graphics modes with SDL
16273154011:DEBUG: found aspect ratio 16:10
16273154011:DEBUG: found aspect ratio 3:2
16273154011:DEBUG: found aspect ratio 4:3
16273154011:DEBUG:Wrote resolution 1280x800 for mod (No mod)
16273154011:DEBUG:Generating EVT_RESOLUTION_MAP_CHANGED event
16273154011:DEBUG: Sent EVT_RESOLUTION_MAP_CHANGED event to 0x7f97ca45d760
16273154011:DEBUG:Generating EVT_FLAG_LIST_BOX_READY event
16273154011:DEBUG: Sent EVT_FLAG_LIST_BOX_READY event to 0x7f97ca7701d0
16273154011:DEBUG:Generating EVT_CUSTOM_FLAGS_CHANGED event
16273154011:DEBUG: Sent EVT_CUSTOM_FLAGS_CHANGED event to 0x7f97ca7701d0
16273154011:DEBUG:Generating EVT_CMD_LINE_CHANGED event
16273154011:DEBUG: Sent EVT_CMD_LINE_CHANGED event to 0x7f97ca7701d0
16273154011:DEBUG:lighting preset Off selected
16273154011:DEBUG:Generating EVT_CMD_LINE_CHANGED event
16273154011:DEBUG: Sent EVT_CMD_LINE_CHANGED event to 0x7f97ca7701d0
16273154018:DEBUG:FlagListManager::DeInitialize(): contents of handler list:
16273154018:DEBUG: handler at 0x7f97ca699770
16273154018:DEBUG: handler at 0x7f97ca7701d0
16273154018:DEBUG:SkinSystem::DeInitialize(): contents of handler list:
16273154018:DEBUG: handler at 0x7f97ca656360
16273154018:DEBUG: handler at 0x7f97ca667f40
16273154018:DEBUG: handler at 0x7f97cd20a910
16273154018:DEBUG: handler at 0x7f97cd20b330
16273154018:DEBUG: handler at 0x7f97ca68dae0

Log closed.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on September 29, 2016, 03:26:48 pm
Thanks for your responses, chief. I'm getting ready for this weekend's GaymerX convention and can't reply today. I'll get back to everyone early next week.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on September 29, 2016, 10:50:54 pm
@chief please try this patch: https://github.com/scp-fs2open/wxLauncher/pull/153  This will make the code explicitly case insensitive.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on October 03, 2016, 08:53:51 am
Are the public builds typically debug or release configuration?  Thinking debug for the test builds at least in case you need logs from a user?
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Iss Mneur on October 03, 2016, 09:27:45 am
For wxLauncher, the public builds are release, though we have made Debug builds available separately so that we can get the log in case of issues.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on October 03, 2016, 10:09:27 am
Ok, I should have a distributable mac release build coming right up then.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on October 03, 2016, 10:29:08 am
wxLauncher Experimental Mac Build 0.12.x line (http://scp.fsmods.net/builds/wxlauncher-mac-20161004-02f6d1.tgz)
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on October 05, 2016, 01:43:20 am
I can try Iss Mneur's patch to fix case sensitivity in FSO build names later. Guess I should test it on Linux too if no one else can.



Collection of replies to the various comments since my last post:


Having a distributable OS X build is certainly good but we still need to get CI working again before we can move forward with 0.12.0 RC3.

Sure, if the scripts now work with Python 2, I can remove Python 3 from the ReadMe. Note that Python is only required to build wxL, not to use it.

For the CI, can't we set up the scripts to build wxWidgets  on the CI ser ver exactly once and then use those built libraries for all future CI tests?

Still not enthusiastic about prebuilt wxWidgets libraries (are they release or debug?) for official use if it requires regex hacking and additional CMake tinkering to get wx-config to work. I really don't think it's that hard to spend the ~5-10 minutes it takes to download, configure, and build the libraries if you copy/paste the commands from the wxL ReadMe. I'm even less enthusiastic about storing the prebuilt libraries in the wxL repo since they take up a lot of space. And I still don't understand why Homebrew requires special patches for wxWidgets 3.0.2 to work when I can use the vanilla 3.0.2 source without issues.

Okay, I guess people can get SDL2.framework from the official SDL2 site rather than the FSO source tree. I'll update the ReadMe.

I don't know if ~/Library/Frameworks is a standard location for storing libraries, but the CMake find_library() command is able to find SDL2.framework if it's stored there. I figure it's a better choice than asking people to put it in /Library/Frameworks since in the first case it's in their home folder rather than a system one. Note that placing the framework there is only required to build wxL, not to run it. It can be removed as soon as the user is finished building wxL.

IIRC wxWidgets 2.8 can be either Unicode or non-Unicode. wxL releases have always been built with Unicode builds of wxWidgets. I think 3.0 is Unicode-only? In which case --enable-unicode is not required to build wxWidgets. Will need to look into that and update the ReadMe if needed.

Yes I'd also prefer Cmd-Q for quitting wxL but I have no idea how to get it working again and am doubtful it's worth trying to track down assuming it's even fixable in the first place.

As for the case where the user has both Homebrew SDL2 and SDl2.framework, the user will need to explicitly specify the path to their SDL2.framework (i.e., set the SDL2_FRAMEWORK CMake variable) when running CMake. The CmakeLists.txt will need to be updated to check if SDL2_FRAMEWORK has already been specified by the user and look for it with the CMake find_library() command if it has not. I don't think there's any way to tell CMake to look for a framework and not a library built by something like Homebrew.

Honestly though, I'm really not sure how much time it's worth investing (and complexity worth adding) in making wxL as easy to build on OS X as possible, given how rarely people need to do it and how few people (only a handful of devs) need to do it, and especially if we don't do these sorts of things for Windows, where building wxL is more common. My $0.02. By complexity I mean the required changes to the CMakeLists.txt. In the 5+ years since I joined the SCP I have never heard of an OS X player having to build wxL.

I don't think there's any value in maintaining 2.8 compatibility except where needed to keep Linux people happy.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on October 05, 2016, 05:35:26 pm
I can try Iss Mneur's patch to fix case sensitivity in FSO build names later. Guess I should test it on Linux too if no one else can.

Mac was already tested and confirmed, guessing he tested on Windows at least, so I doubt there's much besides Linux left to test it on.  I plan on trying to compile wxLauncher for FreeBSD at some point for S&Gs.


Having a distributable OS X build is certainly good but we still need to get CI working again before we can move forward with 0.12.0 RC3.

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.

Sure, if the scripts now work with Python 2, I can remove Python 3 from the ReadMe. Note that Python is only required to build wxL, not to use it.

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.

For the CI, can't we set up the scripts to build wxWidgets  on the CI ser ver exactly once and then use those built libraries for all future CI tests?

Not sure about that.  Could build it every time at least I guess, only an extra few minutes right?  But if we just assembled a prebuilt library and used that for official builds, CI builds, and development, it would solve this problem as well.

Still not enthusiastic about prebuilt wxWidgets libraries (are they release or debug?) for official use if it requires regex hacking and additional CMake tinkering to get wx-config to work. I really don't think it's that hard to spend the ~5-10 minutes it takes to download, configure, and build the libraries if you copy/paste the commands from the wxL ReadMe. I'm even less enthusiastic about storing the prebuilt libraries in the wxL repo since they take up a lot of space. And I still don't understand why Homebrew requires special patches for wxWidgets 3.0.2 to work when I can use the vanilla 3.0.2 source without issues.

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.  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.

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.

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.

I don't know if ~/Library/Frameworks is a standard location for storing libraries, but the CMake find_library() command is able to find SDL2.framework if it's stored there. I figure it's a better choice than asking people to put it in /Library/Frameworks since in the first case it's in their home folder rather than a system one. Note that placing the framework there is only required to build wxL, not to run it. It can be removed as soon as the user is finished building wxL.

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 :)

As for the case where the user has both Homebrew SDL2 and SDl2.framework, the user will need to explicitly specify the path to their SDL2.framework (i.e., set the SDL2_FRAMEWORK CMake variable) when running CMake. The CmakeLists.txt will need to be updated to check if SDL2_FRAMEWORK has already been specified by the user and look for it with the CMake find_library() command if it has not. I don't think there's any way to tell CMake to look for a framework and not a library built by something like Homebrew.

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.

Honestly though, I'm really not sure how much time it's worth investing (and complexity worth adding) in making wxL as easy to build on OS X as possible, given how rarely people need to do it and how few people (only a handful of devs) need to do it, and especially if we don't do these sorts of things for Windows, where building wxL is more common. My $0.02. By complexity I mean the required changes to the CMakeLists.txt. In the 5+ years since I joined the SCP I have never heard of an OS X player having to build wxL.

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...

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.

I don't think there's any value in maintaining 2.8 compatibility except where needed to keep Linux people happy.

If there are any platforms we want to support which have 2.8 as the newest wx in their package manager, I think we should keep 2.8 support around if possible.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on October 06, 2016, 02:01:42 am
wxL fails on Linux with the new patch for case-insensitive FSO build detection. It can't find any builds in the FS2 folder now. :sigh:

It's late and I'm sick with a cold and not able to debug this right now, but for the record here's the log:

Code: [Select]
16280064209:DEBUG:  Opening /home/joshua/.wxlauncher/pro00001.ini
16280064209:DEBUG:  Opened profile named: FOo
16280064209:DEBUG:  Opening /home/joshua/.wxlauncher/pro00000.ini
16280064209:DEBUG:  Opened profile named: Default
16280064209:DEBUG: Searching for profile: FOo
16280064209:DEBUG: Making 'FOo' the application profile
16280064209:DEBUG:Generating current profile changed event
16280064209:DEBUG: Profile Manager is set up
16280064209:DEBUG:Profile 'FOo' saved to '/home/joshua/.wxlauncher/pro00001.ini'
16280064209:STSBR:Profile 'FOo' saved
16280064209:DEBUG:Current config saved.
16280064209:STSBR:Now autosaving profiles.
16280064209:DEBUG:ModsPage is at 0x1db5900.
16280064209:DEBUG:BasicSettingsPage is at 0x1e2c000.
16280064209:DEBUG:TCManager is at 0x1e1cec0.
16280064209:DEBUG:lighting preset Off selected
16280064209:DEBUG:Generating EVT_CMD_LINE_CHANGED event
16280064209:DEBUG:AdvSettingsPage is at 0x1e3d0e0.
16280064209:DEBUG:BottomButtons is at 0x1f67200.
16280064209:STSBR:MainWindow is complete
16280064209:DEBUG:Generating EVT_TC_CHANGED event
16280064209:DEBUG: Sent EVT_TC_CHANGED event to 0x1db5900
16280064209:DEBUG: Sent EVT_TC_CHANGED event to 0x1e2c000
16280064209:DEBUG: Sent EVT_TC_CHANGED event to 0x1f67200
16280064209:STSBR:Ready.
16280064209:WARN :Selected root folder has no FS2 Open executables
16280064209:DEBUG:The current root folder is invalid.
16280064209:DEBUG:Generating EVT_TC_BINARY_CHANGED event
16280064209:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x1c90ba0
16280064209:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x1e2c000
16280064209:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x1f67200
16280064209:DEBUG:current flag file processing status: 1
16280064209:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16280064209:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1b9bb50
16280064209:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1e2c000
16280064209:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1e3d0e0
16280064209:DEBUG:The current profile's listed FSO executable 'fs2_open_3_7_5_x64' is invalid.
16280064209:DEBUG:Generating EVT_PROXY_RESET event
16280064209:DEBUG: Sent EVT_PROXY_RESET event to 0x1e3d0e0
16280064209:DEBUG:Initializing flag file processing.
16280064209:DEBUG:current flag file processing status: 4
16280064209:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16280064209:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1b9bb50
16280064209:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1e2c000
16280064209:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1e3d0e0
16280064215:DEBUG:Generating current profile changed event
16280064215:DEBUG: Sent current profile changed event to 0x1d12000
16280064215:DEBUG: Sent current profile changed event to 0x1e1cec0
16280064215:DEBUG: Sent current profile changed event to 0x1e2c000
16280064215:MSG  :Profile Default is now the active profile.
16280064215:DEBUG:Generating EVT_TC_CHANGED event
16280064215:DEBUG: Sent EVT_TC_CHANGED event to 0x1db5900
16280064215:DEBUG: Sent EVT_TC_CHANGED event to 0x1e2c000
16280064215:DEBUG: Sent EVT_TC_CHANGED event to 0x1f67200
16280064215:WARN :Selected root folder has no FS2 Open executables
16280064215:DEBUG:The current root folder is invalid.
16280064215:DEBUG:Generating EVT_TC_BINARY_CHANGED event
16280064215:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x1c90ba0
16280064215:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x1e2c000
16280064215:DEBUG: Sent EVT_TC_BINARY_CHANGED event to 0x1f67200
16280064215:DEBUG:current flag file processing status: 1
16280064215:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16280064215:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1b9bb50
16280064215:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1e2c000
16280064215:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1e3d0e0
16280064215:DEBUG:The current profile's listed FSO executable 'fs2_open_3_7_5_x64' is invalid.
16280064215:DEBUG:Generating EVT_PROXY_RESET event
16280064215:DEBUG: Sent EVT_PROXY_RESET event to 0x1e3d0e0
16280064215:DEBUG:Initializing flag file processing.
16280064215:DEBUG:current flag file processing status: 4
16280064215:DEBUG:Generating EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event
16280064215:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1b9bb50
16280064215:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1e2c000
16280064215:DEBUG: Sent EVT_FLAG_FILE_PROCESSING_STATUS_CHANGED event to 0x1e3d0e0
16280064244:DEBUG:FlagListManager::DeInitialize(): contents of handler list:
16280064244:DEBUG: handler at 0x1e2c000
16280064244:DEBUG: handler at 0x1e3d0e0
16280064244:DEBUG:SkinSystem::DeInitialize(): contents of handler list:
16280064244:DEBUG: handler at 0x1ba8400
16280064244:DEBUG: handler at 0x1d98c70
16280064244:DEBUG: handler at 0x1d12000
16280064244:DEBUG: handler at 0x1b764d0
16280064244:DEBUG: handler at 0x1db5900

Log closed.


Output from ls in my FreeSpace2 folder:
Code: [Select]
data                Root_fs2.vp       stu_fs2.vp     warble_fs2.vp
FS2_OpEN_3_7.2      smarty_fs2.vp     tango1_fs2.vp
FS2_open_3_7_4_x64  sparky_fs2.vp     tango2_fs2.vp
fs2_open_3_7_5_x64  sparky_hi_fs2.vp  tango3_fs2.vp

For testing, I just took a build of master and made a few copies with new filenames.


EDIT: I will reply to chief's replies during the day. It's late and I'm sick and need sleep.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: jg18 on October 07, 2016, 02:01:24 am
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 :mad: 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.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on October 07, 2016, 09:44:19 am
The FSO community is the only development community I've ever really been involved with outside of work.  I got involved in FSO because of my involvement with FotG.  However, for quite a while after I was working with FotG, I had no real interest in messing with FSO.  I had tried several times back when the VCS was still CVS and the build system was not terribly well documented or supported.  This seemed to be because the devs had gotten used to knowing what was needed and kept up with changes, but it increased the barrier to entry for new developers.  Shortly after the move to SVN, the build system had been stabilized a bit more and I could make a build without a bunch of configuring and tweaking things, all of which were new concepts to me as a very new C++ developer.  But once I had it figured out, I was able to make improvements to the cross platform support, submit some patches, and even wrote the original nightly build system, all because the barrier to entry had been lowered enough for me to figure some things out.  But initially I remember running into issues with wading through dependency requirements that I found offputting at first.  We can act all day like devs shouldn't be offput by those kinds of things but the fact is, if a new developer comes by this project, it's like a new TV show.  If it takes too much effort to become interesting, ADD will kick in and they'll move on to something else.  Only if they had a real need or desire will they maybe give it another shot later, as I did.  But many of those devs aren't going to pop into IRC and let us know they had issues.  They'll just be gone.  We won't know of the issues they ran into.  Just because the build system works well enough for us doesn't mean it can't be improved upon, and the barrier to entry lowered even further.  It kind of feels like arguing against client side form validation when you already have server side validation in place.  Sure, you don't need it, and the server side works perfectly well.  But if the experience can be improved further using concepts that are already in place elsewhere, where is the harm?  It can only benefit us in the long wrong if done correctly.

As I was writing this, I removed the patches from my wx directory.  It now compiles correctly somehow.  I have upgraded to Xcode 8, not sure if that had anything to do with it or not.  This is for the release build.  I don't know why there would be issues with asserts from using release libs with a debug wxL build.  I can provide prebuilt un-patched debug build probably as well though, if those build too, so that would no longer have to be an issue.

I merely thought that mirroring the official Homebrew wxMac release meant that anyone using wxmac from Homebrew already should expect wxL built on the same code to work just as well as any wxMac app they might build themselves, not that we should support Homebrew in any way.  Don't get me wrong on this please, I honestly hate needing homebrew for anything, except the occasional command line utility like htop or something.  It seems to cause more issues with projects like this when the wrong libs get found and used.

Guess I forgot the markdown requirement was mentioned in the mac section, my bad.  Thought it had only been covered up in general requirements or something.

I don't really expect /tmp/wxmac/{release,debug} to be taken.  /tmp is a standard path, and the likelihood something else already exists there should be incredibly low.  That said, proper error handling in the implementation could take care of the low chance that it happens.  We would simply have to mention that the folder needs to be removed from /tmp.  Flow could be like:

if no wxWidgets specified on command line or found via auto detection:
  if /tmp/wxmac exists:
      if exists /tmp/wxmac/<release|debug>/IS_FSO_WX_BUILD: use that location
      else: throw warning/error that this location is in use already (highly unlikely but should be accounted for)
  else:
    download and extract FSO WX build to /tmp/wxmac/<release|debug>
    touch /tmp/wxmac/<release|debug>/IS_FSO_WX_BUILD empty file so that CMake knows this is our lib and not a pre-existing file.

This should allow us to download and extract once, and trust that the lib is safe to use as long as the IS_FSO_WX_BUILD file remains in place.

If I can manage to compile wxLauncher on FreeBSD I can probably reproduce the error you're getting on Linux, if so I'll look into it. IssMneur might have some more thoughts on that too, as I thought he had a Linux development environment too.  I wouldn't spend more time on it than you are comfortable doing right now.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: chief1983 on October 07, 2016, 09:51:41 am
Debug built fine too, so I can build both release and debug wxWidgets 3.0.2 without patches on my Mac now somehow.

Edit:  If we were to implement support for the prebuilt libs, I have a proposed update to the Readme already typed up so no one else needs to mess with that.  It also covers updating the SDL2 and python recommendation changes.  I have left manually compiling wxWidgets as the 'default' method, with only mentioning that the prebuilt lib can be used as an alternative.  We could reverse the direction the readme encourages the user to go but I figured you would prefer it stay closer to something like this.  I can submit a PR now that only covers the SDL2.framework/python2 changes for now.  The prebuilt lib part could just be added later if we get that support added.

Code: [Select]
Building - OS X (tested on 10.11, El Capitan)
=============================================
- Get Xcode from the Mac App Store (used 7.3.1)
This will include git which will be needed later.
- Get Markdown for Python (link is provided above). (used 2.6.6)
This will require root privileges to install globally.
- Clone the wxLauncher repository.
- Get CMake 3 (used 3.6.1).
- Get the latest stable version of wxWidgets 3 (used 3.0.2). Once you've
downloaded and extracted the source tarball, do these things, assuming 3.0.2:
    * cd wxWidgets-3.0.2/
    * Either "mkdir build-debug" or "mkdir build-release" (your choice)
    * cd <TheBuildFolderYouJustMade>
    * Type the following to configure, adjusting according to the notes
    that follow:
    * ../configure --enable-stl --enable-unicode --enable-debug
    --disable-shared --with-macosx-version-min=10.9 CC=clang CXX=clang++
    CXXFLAGS="-stdlib=libc++ -std=c++11"
    OBJCXXFLAGS="-stdlib=libc++ -std=c++11" LDFLAGS=-stdlib=libc++
        - If you want a release build rather than a debug build, leave out
       the '--enable-debug'
    * make
If you skip this step, a prebuilt lib will be downloaded for you to /tmp/wxmac.
- Get SDL2 for Mac: https://www.libsdl.org/download-2.0.php

Extract the SDL2.framework and copy it to your
/Users/<YourUsername>/Library/Frameworks folder. Create the Frameworks
folder if it does not exist.
- Run CMake either by using cmake at the command line or by using the
CMake.app GUI, selecting Xcode as your generator.
    - A few notes on configuring the CMake variables:
        * Set wxWidgets_CONFIG_EXECUTABLE to point to the version of
        wxWidgets you built. wxWidgets_CONFIG_EXECUTABLE is located at
        /yourWxWidgetsBuildFolder/wx-config
        * Omit the wxWidgets_CONFIG_EXECUTABLE option to use the prebuilt lib.
    * cd <wxLauncherSourceFolder>
    * mkdir build
    * cd build
    * /path/to/CMake.app/Contents/bin/cmake -G Xcode
    -DwxWidgets_CONFIG_EXECUTABLE=/path/to/wxWidgets/Build/Folder/wx-config
    -DUSE_OPENAL=1 ../
- Once you have your Xcode project set up, build the "ALL_BUILD" target to
build wxlauncher.app in /wxLauncherBuildFolder/SelectedBuildConfig/ , or
type "xcodebuild -configuration <SelectedBuildConfig>" at the terminal in
your wxLauncher build folder. Make sure that the build configuration you
choose (Debug or Release) matches the build configuration you used when
you built wxWidgets (if you built it yourself).

Important known issues on OS X:
- After startup or after a FS2 Open binary is (re-)selected, checkboxes on
the advanced settings page may not appear until after a moment or after
the user interacts with the advanced settings page, such as by clicking on
the flag list.
Title: Re: wxLauncher Test Builds [Updated: 2016-09-04]
Post by: Yarn on March 30, 2017, 02:34:20 pm
I discovered today that wxLauncher 0.12.0 RC2 isn't writing the correct joystick GUID to fs2_open.ini if an XInput device is selected. More information can be found in this post: http://www.hard-light.net/forums/index.php?topic=93352.msg1845475#msg1845475 (http://www.hard-light.net/forums/index.php?topic=93352.msg1845475#msg1845475)

I'm using Windows 7 SP1 64-bit, by the way.