OSX Build problems
Pablo Wolter
pwolter at gmail.com
Tue Mar 15 10:30:10 PDT 2016
So this:
$ git shortlog -s -n | egrep -i "jeroen|massar"
$ git shortlog -s -n | grep -i "hohndel"
3799 Dirk Hohndel
invalidates feedback?
What that number needs to be to be able to get into the "club".
Don't bother answering .... I think I'm out.
On Tue, Mar 15, 2016 at 10:20 AM Dirk Hohndel <dirk at hohndel.org> wrote:
> 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
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
--
Gracias,
Pablo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160315/38da831c/attachment-0001.html>
More information about the subsurface
mailing list