[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... ]
On 2016-03-15 18:20, Dirk Hohndel 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. 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. > In general I appreciate patches or concise bug reports from those who > actually try to do builds and for whom the builds fail. Yep, full ack on that. 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. >> 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. >> 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 Homebrew does not touch user's home dirs, it installs systemwide, thus /usr/local/Cellar/qt5/5.5.1_2/ for that version, with symlinks in /usr/local/ in various places to glue that all in place. I think this is also likely where a lot of differences in the build can occur: people using "local Qt" and then "homebrew" and then of course lingering files. Hence my intent of a "clean" OSX install to make sure we catch all the corners. As noted, proper patches to follow... [..] >> 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. I primarily noted that in the style of "I have a learning curve to figure out what the heck is going wrong" :) And I agree with your sentiment btw, fully understood. While tool X might not be my ideal thing, it will just be another thing to figure out and learn about. [..] >> (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. Well, there is indeed homebrew libxml (if one installs that) and then the system one. The system one (well, Xcode) lives in the above path, seems the dylib is: -rwxr-xr-x 1 root wheel 2395024 Jan 14 03:05 libxml2.2.dylib Thus that might run a bit behind 2.9. Cmake/configure is picking it up though for subsurface, but the actual compile then fails in the end. >>>> 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 The 'use bash' suggestion was a comment on the $HOME patch that is the start of this thread. I am using the bash call, as that is what is in the instructions (the INSTALL file in the repo). > 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? As much time till it works consistently as it is in. Hence why I noted to use a empty/clean OSX Install to make sure that it works. > 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. Please note that I was not complaining AT ALL... I was only providing initial feedback on a similar issue that obviously somebody else was running into too. > $ git shortlog -s -n | egrep -i "jeroen|massar" > > $ git shortlog -s -n | grep -i "hohndel" > 3799 Dirk Hohndel Not a fair comparison really, me being the new user trying to help out. I am fully fully fully aware of who sticks time in the code and appreciate it immensely. Hence why I am trying to ___dive__ in and provide some initial details. As I noted, proper patch requests etc to follow.... but first got to make it compile properly, then I'll make a clean VM and document what steps are missing, what goes wrong and make patches based on that. Greets, Jeroen _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
