OSX Build problems

[Dirk Hohndel]

On Tue, Mar 15, 2016 at 04:32:37PM +0100, Jeroen Massar wrote:
> >>
> >> There are errors while building libdivecomputer, it tries also to
> >> build examples/dctool_parse.c where in calls of the type
> >> VENDOR_MODEL_parser_create a fourth parameter “serial” is missing. But
> >> I guess since this is an example this is save to ignore.
> > 
> > It is. But the best is to just remove the useless build of the
> > examples... in the build.sh add "--disable-examples" to the configure
> > call for libdivecomputer
> > 
> >> More serious is in subsurface/scripts/build.sh
> [..]
> >> This does not find ~/Qt/5.5 for me on my Macs.
> 
> I've been attempting to build subsurface also for a bit, with little
> success. The dctool indeed hit me, but as per IRC, that was easily
> circumvented... The QT thing seems to be way more annoying though.

The funny thing is - we have about four people (optimistically speaking)
who build on Mac and two who build for Windows (one ON Windows). So to me
it constantly feels like I am spending a LOT of time on making sure
everyone can build for not a lot of value.

In general I appreciate patches or concise bug reports from those who
actually try to do builds and for whom the builds fail.

> My current list of homebrew build depends is quite a bit more than on
> the website:
> brew qt5 install automake autoconf libtool libusb libssh2 pkgconfig hidapi

So let's fix that.
Oh, that's not complete, either. It misses asciidoc (ok, I guess one could
call that optional) and cmake (definitely not optional).

OK, done.

> The QT part I fixed in my build with (build.sh):
> 8<-------------------
>         elif [ -d "~/Qt/5.6" ] ; then
>                 export CMAKE_PREFIX_PATH=~/Qt/5.6/clang_64/lib/cmake
> +       elif [ -d /usr/local/opt/qt5/lib ] ; then
> +               export CMAKE_PREFIX_PATH=/usr/local/opt/qt5/lib/cmake

Is that the default path with homebrew? I have my own Qt installation
instead of the homebrew one

>         else
>                 echo "cannot find Qt 5.5 or 5.6 in ~/Qt"
>                 exit 1
>         fi
> ----------------->8
> 
> and then also added:
> 8<------------------
>  cmake -DCMAKE_BUILD_TYPE=Release -DQTONLY=TRUE -DQT5BUILD=ON \
>         -DCMAKE_INSTALL_PREFIX=$INSTALL_ROOT \
>         -DBUILD_MARBLE_TESTS=NO \
>         -DWITH_DESIGNER_PLUGIN=NO \
>         -DBUILD_MARBLE_APPS=NO \
> +       -DCMAKE_MODULE_PATH=$CMAKE_PREFIX_PATH \
>         $SRC/marble-source
> ....
>         cmake -DCMAKE_BUILD_TYPE=Release \
>                 -DCMAKE_INSTALL_PREFIX=$INSTALL_ROOT \
> +               -DCMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH \
> +               -DCMAKE_MODULE_PATH=$CMAKE_PREFIX_PATH \
>                 -DBUILD__TESTS=NO \
>                 $SRC/grantlee
> ....
>         mkdir -p $SRC/subsurface/$BUILDDIR
>         cd $SRC/subsurface/$BUILDDIR
> -       export CMAKE_PREFIX_PATH=$INSTALL_ROOT/lib/cmake
> +       export
> CMAKE_PREFIX_PATH="$INSTALL_ROOT/lib/cmake;${CMAKE_PREFIX_PATH}"
>         cmake -DCMAKE_BUILD_TYPE=Debug .. \
>                 -DSUBSURFACE_TARGET_EXECUTABLE=$SUBSURFACE_EXECUTABLE \
>                 -DLIBGIT2_INCLUDE_DIR=$INSTALL_ROOT/include \
> @@ -227,6 +233,7 @@ for (( i=0 ; i < ${#BUILDS[@]} ; i++ )) ; do
> 
> -DLIBDIVECOMPUTER_LIBRARIES=$INSTALL_ROOT/lib/libdivecomputer.a \
>                 -DMARBLE_INCLUDE_DIR=$INSTALL_ROOT/include \
> 
> -DMARBLE_LIBRARIES=$INSTALL_ROOT/lib/libssrfmarblewidget.$SH_LIB_EXT \
> +               -DCMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH \
>                 -DNO_PRINTING=OFF
> ----------------->8
> (better patch to follow, when the whole thing finally actually builds,
> something with finding time to do so though ;)

Yeah, tell me about how that feels.

> that makes Subsurface (and grantlee actually) find QT perfectly fine
> when installed from homebrew (brew install qt5; which provides 5.5.1 at
> the moment).
> 
> The next problem though seems to be with libxml... apparently some
> include path is not being passed properly $somewhere... (and I have
> never been a fan of either autoconf/automake let alone cmake... but the
> fact that build.sh exists and does not catch several dependencies being
> missing underscores what I think about those "tools")

So fix them. It builds for me. It builds for Robert, it builds for Tomaz.
So if it doesn't build for you let's figure out why and fix it. The
passive aggressive '...what I think about those "tools"' doesn't really
encourage me to go out of my way to guess what might be wrong for you.

> 8<---------------------
> Scanning dependencies of target subsurface_corelib
> [ 29%] Building C object
> subsurface-core/CMakeFiles/subsurface_corelib.dir/cochran.c.o
> In file included from src/subsurface/subsurface-core/cochran.c:12:
> src/subsurface/subsurface-core/dive.h:38:10: fatal error:
> 'libxml/tree.h' file not found
> #include <libxml/tree.h>
>          ^
> 1 error generated.
> make[2]: ***
> [subsurface-core/CMakeFiles/subsurface_corelib.dir/cochran.c.o] Error 1
> make[1]: *** [subsurface-core/CMakeFiles/subsurface_corelib.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs....
> --------------------->8
> 
> I am trying to add 'debug' output to Cmake to see where the heck this
> goes wrong. Of course it also just continues till multiple errors hit
> instead of barfing out at the first one, thus the above happens in
> multiple places. As noted, libxml2 lives in the Apple OSX SDK, hence the
> path is $magic, but it should also be the default include path, which is
> what is surprising me here quite a bit. Though it should be
> /usr/include/libxml2/<libxml/tree.h> hence, the -I/usr/include/libxml2/
> should be passed along. (Real path is of course the magically long
> version:
> /Application/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/libxml2/
> )

Oh well, let me guess anyway... I'm picking it up from homebrew it seems:

-I/usr/local/Cellar/libxml2/2.9.3/include/libxml2

Which makes me think that this might needed on the brew install line above
as well.

> >> I really don’t speak shell but it seems in that in the file test ~ is
> >> not interpolated properly. If I replace it by $HOME it works. Here is
> >> a patch that does this.
> > 
> > Odd - it worked one of my Macs, but fails on the others. I don't think I
> > installed a different shell but it's possible...
> > 
> > Can you send a second patch to fix the problem above?
> 
> Watch out that one is really using "bash" and not any other kind of
> shell when executing the build.sh, as that might make a huge difference...

So call 

bash ./scripts/build.sh

Again - how much time do you think I want to spend on making sure this
works out of the box on every OS on the face of the planet? Versus time I
spend on working on the code, on releases, on the website, on the backend
server, on answering support questions and on oh five hundred other things.

Complaining is cheap.

$ git shortlog -s -n | egrep -i "jeroen|massar"

$ git shortlog -s -n | grep -i "hohndel"
  3799  Dirk Hohndel


/D