Never-ending story: Mac and mobile

[Dirk Hohndel]

On Wed, Dec 16, 2015 at 08:12:07PM -0800, K. "pestophagous" Heller wrote:
> 
> I have been curious to attempt a mac subsurface build for a while, and
> Robert's report somehow inspired me.
> 
> Success! Tonight both Subsurface-mobile.app and Subsurface.app are
> built and launchable on my Mac El Capitan computer.
> 
> For reasons i cannot explain, i did *not* need to invoke homebrew to
> fix any libssh2 issues. (but this seems strange, i would have expected
> to need to do that.)
> 
> I did need these additional homebrew items:
>     brew install hidapi
>     brew install  automake autoconf libtool
> 
> 
> "not loaded: @executable_path/lib/libssrfmarblewidget.21.dylib"
>     ... also did *not* happen to me.
> 
> However, in regards to the marble dylib, I can confirm the following:
>     there is a point in subsurface/master/scripts/build.sh where the
> following is scripted:
> 
> #in order for macdeployqt to do its job correctly, we need the full
> path in the dylib ID
> cd $INSTALL_ROOT/lib
> NAME=$(otool -L libssrfmarblewidget.dylib | grep -v : | head -1 | cut
> -f1 -d\  | tr -d '\t' | cut -f3 -d/ )
> 
> echo $NAME | grep / > /dev/null 2>&1
> if [ $? -eq 1 ] ; then
> install_name_tool -id "$INSTALL_ROOT/lib/$NAME" "$INSTALL_ROOT/lib/$NAME"
> fi
> 
> -----
> 
> ... if for any reason that "install_name_tool -id" command does not
> execute, then the dylib id will be:
> 
> @executable_path/lib/libssrfmarblewidget.21.dylib
> 
> and if the subsurface app executable is linked to that dylib (when its
> "id" is still like that), then that would reproduce the error reported
> by Robert.

Yes, I'm aware of that. But how would that not get executed if you run the
script. I'm confused.

> So, i think there is merit in Sebastian's hypothesis that building
> non-mobile, then mobile, then non-mobile somehow resulted in the good
> fortune of that install_name_tool trick actually doing its work
> finally.

There clearly are some potential pitfalls here. Without a doubt. This is
not fool proof. And I have plenty of evidence that switching between
desktop and mobile builds in the same build directory may be cause for
nose bleeds, excema and sleep deprivation.

> Two other strange things that I had to do for my build to succeed:
> 
> 1. for the mobile app, i had to manually run
> macdeployqt Subsurface-mobile.app
> -qmldir=Subsurface-mobile.app/Contents/Frameworks/qml
> -executable=Subsurface-mobile.app/Contents/MacOS/Subsurface-mobile
> -always-overwrite

AHHH. That may be the magic incantation that I've been missing.
I thought I finally had the right one in my cmake version but then I ran
into that error as well. And then I tried twice more and it worked.
I'll try with a clean build directory and this incantation and see if that
does the trick.

> 2. i had to edit "subsurface/CMakeLists.txt" to make sure this would
> be in the linker:
> 
> -framework CoreFoundation

I had this a long time ago (I think that's when we still built with qmake)
that the CoreFoundation was missing. I don't recall ever seeing this with
cmake.
And since I now upgraded my laptop to El Capitan I'm pretty sure that I
have a very similar build environment to you.

> As I said, my build steps were all done on El Capitan (os x 10.11).
> However, if i am the only El Cap user who needs to add the
> CoreFoundation business, then that might be due to something bad in my
> xcode/clang toolchain.  I am using Xcode 6.2 left over from when this
> computer was running 10.9.

So my experience with the El Capitan upgrade was that it made an utter
mess out of my tool chain and I ended up doing a complete remove and fresh
install of the latest XCode. So that may be part of the problem you are
having.

> Oh guess what!  One of my problems mysteriously disappeared, too!
> 
> I just did "rm -rf" on my Subsurface-mobile.app, then rebuilt it.  I
> wanted to reproduce the problem that forced me to run macdeployqt to
> get the QtQuick qml files in the right spots.
> 
> After my "rm -rf" and rebuild, Subsurface-mobile.app just launches!
> Now it did not require the manual macdeployqt step.

See, that's exactly what I keep seeing. There is a weird order dependency
thing going on here. But I'll simple edit the arguments for the
macdeployqt invocation that are run at "make install" time to reflect what
you showed above and hopefully that will make things more consistent if
nothing else...

Thanks for working on this and especially thanks for documenting it in
detail!

/D