Windows binary saga

Dirk Hohndel dirk at hohndel.org
Tue Sep 22 09:05:06 PDT 2015


On Tue, Sep 22, 2015 at 06:38:11PM +0300, Lubomir I. Ivanov wrote:
> On 22 September 2015 at 17:26, Dirk Hohndel <dirk at 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
         ^^^^
	     \__HATE :-)

> > 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.

I've taken your patch. Tomaz is planning to rewrite the cmake files,
anyway, so I wouldn't worry too much right now.

> > 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.

Yeah, I skipped that one :-)

> > 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"!

That looks useful. Something I'll try to mimic on my Windows laptop.

> (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.

Autotools are evil squared. We have a couple of packages that really do
best when built with autotools. libdivecomputer of course. But also
libcurl and libzip. Both have started to shift to cmake, but in both cases
it seems that autotools based build is easier to deal with.

I'll make a note to try and switch them all to using cmake to reduce my
dependency on autotools in plan A.

I'm curious about your build.cmd file for libdivecomputer. I know that Jef
cross builds his binaries for Windows as well... have you talked to him
about what's broken for native builds? I would assume that he'd be open to
receiving suggestions to improve that.

> NSIS wise, makensis.exe part of the Win32 package and i've used it
> back in the GTK version.

Win32 package? you lost me.

> > 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! :-)

I'm reasonably aware of that :-/

> 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. :-(

Hrmpf.

> keywords: sh.exe, pkg-config.exe, cmake, ln -s, etc...

*deep*sigh*

Let's see how plan A progresses. But fundamentally... this is something I
want to continue to tackle, even if I get the cross builds to work again.
I have to think that this would make debugging some of our Windows
problems so much easier. It's fundamentally why I broke down and wasted
the money on an ugly monster 15" HP laptop (the cheapest thing I could get
with decent CPU / RAM and Windows 10 - and as added benefit it has a
1366x768 screen - yes, 15.4" screen at 1366x768 resolution) which will
remind me to keep Subsurface usable on such screen sizes...

> > 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.

Once I have something that builds again (since I retooled everything again
last night) I'll let you know.

You're never on IRC anymore... often that's the better way to discuss
things like this...

/D


More information about the subsurface mailing list