On 22 September 2015 at 17:26, Dirk Hohndel <d...@hohndel.org> wrote: > On Tue, Sep 22, 2015 at 03:05:16PM +0300, Lubomir I. Ivanov wrote: >> >> update: >> >> i was able to get the tests and marble to work. >> attached is a patch to add the MARBLE_FROM_PKGCONFIG. i know these >> _FROM_PKGCONFIG are mostly for me, but please apply it. > > No problem. > I do have the "if (NOT NO_MARBLE)" logic we have. My brain doesn't like > the double negative. >
do you wan't me change the patch so that the "if (NO_MARBLE)" is on top? i do sort of need this patch to be able to build Marble (i.e. use pkg-config) on Win32. >> the docs are problematic... >> Documentation/Makefile does not work with what is distributed for >> Win32 (e.g. a 1MB zip package). > > You don't need to be able to build the docs, only to install them :-) > I will build them here and create the html.git files again and that should > be all you need > ok, i see. > >> so apart from NO_DOCS=0, the only thing i'm not building at the moment >> is FTDISUPPORT=1, but that's probably doable as well. > > As I said in the other email from my phone, that's only needed for Android. > understood, i guess i can now build Subsurface with FTDI support on Win32 for no apparent reason what so ever. if the patch is redundant, please don't apply it. > But just so that I can work on a plan B... let me ask you a bit about your > Windows setup. > > a) which shell do you use? git shell? MSYS (which hasn't been updated in > three years)? something else? i have msys-git which is pretty much git wrapped in the msys shell. i haven't updated that in a couple of years at least. it says: > git --version git version 1.7.11.msysgit.0 the whole thing is installed in c:\bin\git the most important folder in there is c:\bin\git\bin which holds things like sh.exe, cut.exe, touch.exe, git.exe and so on. said bin folder is in PATH. that being said i don't use the sh.exe shell directly - i use cmd.exe, but mind that tools like make and cmake do use it if it's in PATH. > b) which libraries do you build from source (I assume at least > libdivecomputer, libssrfmarblewidget, libgit2), where do you use > precompiled binaries (I assume Qt)? everything except Qt! i used to have precompiled windows binaries (libxlst, libxml, etc) but those were terribly out of date, so i've switched to building everything from source, while testing my nervous system. > c) which tool chain do you use? MinGW 4.92 32bit? Again, from where (you > apparently can get that with QtCreator or in context of MSYS or...) today, when i installed Qt5.5 from the official "offline download" from their website, there was a bundled toolchain mingw-gcc-4.9.2-dwarf-32bit, it installs (e.g.) in c:\bin\qt\<version>\tools i just move this folder to c:\bin\mingw and put c:\bin\mingw\bin\ in PATH, this is now my default toolchain. if i decide to switch toolchains i have a bunch of folders there: mingw mingw_3.4.5 mingw_4.4 mingw_4.6 mingw_4.7 mingw_4.8 mingw_4.8.2_qt mingw_4.8_64 switching toolchains is a matter of renaming folders at this point as all have "bin"! (you might have to create a copy of mingw32-make.exe named make.exe if it's missing) > d) what about makensis? autotools? > i say no to autotools and i build i the libraries without it, whatever hacks needed - e.g. libdivecomputer for that i have a custom Makefile - not even a makefile it's just a build.cmd file. the auotools authors really didn't understand the target platform when they ported the toolset. NSIS wise, makensis.exe part of the Win32 package and i've used it back in the GTK version. > Basically I'd love to not take your 4GB of preconfigured stuff but to be > able to bring this up independently so I understand how the pieces fit > together. > WARNING! major hair splitting pain can ensue in such actions! :-) if you think that the MXE issues are a tough cookie, this is on a whole another level of "not cool" and there is a lot of manual work, creating .CMD wrappers, and more wrappers. :-( keywords: sh.exe, pkg-config.exe, cmake, ln -s, etc... > In the meantime (talking about Plan A) I got a lot further last night > building Qt with debugging enabled. QtWebKit still fails to build, but > it feels like I'm getting closer. > > Maybe I'll be able to to create an installer with debugging symbols after > all :-) > good to hear. do tell, if you wan't be to test something. lubomir -- _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface