On Tue, Mar 15, 2016 at 3:16 PM, Jeroen Massar <[email protected]> wrote:
> On 2016-03-15 18:59, Dirk Hohndel wrote: > > On Tue, Mar 15, 2016 at 06:42:21PM +0100, Jeroen Massar wrote: > >> [TLDR: Full intent to provide proper patches, but I need it then to > >> build first as then I can debug the real problem: why the heck I get > >> segfaults when just running the tool and asking it to download from my > >> watch ;) --- note the smileys and good intentions throughout... ] > > > > Excellent! Sorry for my grumpy email. > > Shite happens, good that I have a thick skin (keeps me quite warm most > of the time as well, unfortunately not warm enough to not need a thick > piece of neoprene when diving Swiss lakes ;) > > >> On 2016-03-15 18:20, Dirk Hohndel wrote: > >>>> > >>>> 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. > >> > >> Understood, hence why my target is to, when the build works, do a clean > >> build to make sure the build instructions are sane for everybody who > >> follows and provide those details so that it can be replicated. > > > > Looking forward to that. I assume you are building master and not > > v4.5-branch - I may want to make sure I track your patches for that as > > well so it's easier to build 4.5.4. > > Yep, I am going against master. > > The build script nicely pulls in the relevant other repos, which is a > useful thing to do. > > >> I just did not get a full build going yet, and as I noticed the patch > >> for the path of Qt, thought I add my few intermediary cents just in case > >> somebody else knew how to attack the problem. > > > > Since there are a few of us who have builds going, I'm sure we can figure > > this out. > > > >>>> 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. > >> > >> Great, thanks. > >> > >> As noted, will test on an empty OSX install and then record all the > >> individual steps when I get it build, thus making sure that rebuilding > >> will be easy peasy for everybody in the future. > > > > add libxml2 to that list and see if that fixes your problem with the > > include path. > > Adding: set(CMAKE_VERBOSE_MAKEFILE ON) to the CMakeLists.txt makes me a > bit wiser that there seems to be a detection issue on my box, as the > actual compile command is: > > cd /Users/jeroen/git/subsurface/subsurface/build/subsurface-core && > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc > -DBT_SUPPORT -DQT_BLUETOOTH_LIB > [... lots of stuff ...] -I/usr/include/libxml2 [... more stuff ] > -c /Users/jeroen/git/subsurface/subsurface/subsurface-core/cochran.c > In file included from > /Users/jeroen/git/subsurface/subsurface/subsurface-core/cochran.c:12: > /Users/jeroen/git/subsurface/subsurface/subsurface-core/dive.h:38:10: > fatal error: 'libxml/tree.h' file not found > > > yeah... that is not going to work, as /usr/include/ really does not > exist on this box ;) > > I will figure out why/how it thinks that is correct. > > > Note btw that the homebrew version of libxml2 is not linked in > /usr/local/ per default, thus I don't think that cmake will find it > either even if you have it installed, as: > > /usr/local/Cellar/libxml2/2.9.3/lib/cmake/libxml2/libxml2-config.cmake > /usr/local/Cellar/libxml2/2.9.3/lib/pkgconfig/libxml-2.0.pc > I found this while searching for the cmake stuff for brew, maybe it helps? http://stackoverflow.com/questions/1487752/how-do-i-instruct-cmake-to-look-for-libraries-installed-by-macports usually I just add the LD_LIBRARY_PATH, DLYB_LIBRARY_PATH and PATH pointed to the brew bin and lib dirs, this makes CMake works correctly most of the time are definitely outside the cmake search path. > > I'll read up on how: > /usr/local/Cellar/cmake/3.5.0/share/cmake/Modules/FindLibXml2.cmake > > gets used, as that discovers the include path and obviously that goes > wrong on my box. > > [..] > >> I primarily noted that in the style of "I have a learning curve to > >> figure out what the heck is going wrong" :) > > > > And I primarily responded in the style of "I'm pissed off by now". > > Sorry about that. > > I have had this exact situation: 100 people complain, and then when you > have had it, you reply to person 101 who actually was not ;) > > Happens, next! > > [..] > >> Not a fair comparison really, me being the new user trying to help out. > > > > Yes. I agree. That was cheap and uncalled for. My apologies. > > No worries ;) > > Greets, > Jeroen > > > > > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
