dirk at hohndel.org
Sat Nov 26 07:56:12 PST 2011
On Sat, 26 Nov 2011 17:03:03 +0200, "Lubomir I. Ivanov" <neolit123 at gmail.com> wrote:
> basically in the lost email to the mailing list i was going to propose to
> maintain the win32 packaging,
> but i'm sure you can handle all that with the cross build tools. also you can
> upload the win32 installer directly to your site, while i will have to send
> updates on each version increase or link from dropbox or another site...
I'm happy to have your help in keeping things building and working under
Windows - I don't really use Windows much and simply test my binaries in
a VM. And now I don't have a divecomputer that I can download from with
libdivecomputer (right now I only have access to a uemis Zurich - the
Gecko I was using to test got lost on the last dive trip), so my testing
ability is even more limited (but I'm planning to get a new backup
> > I also believe I've fixed the typecast warnings
> > that you provided a patch for a while ago (but of course the patch no
> > longer applies with the refactored code - it also dropped the TEXT()
> > macro which my reading of the reference docs makes me believe is
> > incorrect).
> all looks ok in those parts. i only get a couple of mingw-win32 related warnings
> in libdivecomputer.c which can be easily fixed. i can send a patch when i get a
Oops - I thought I had a warning free build. Missed that one.
BTW: I didn't get a warning for the LPCTSTR casts. If you are using
mingw as well (shouldn't matter that I'm using it to cross build and you
are using it natively), then I wonder why you see warnings that I don't
> >> 2) i have a folder over here called c:\dev\linuxlibs\... containing all the
> >> needed libraries + a pkg-config setup (.PC files). would it be ok to zip this
> >> one as well and provide it for download from the website. would this violate
> >> licenses ?
> > See above. I don't think so. As I am cross compiling I am taking a
> > different approach, though. I assume people install the cross compiled
> > MinGW packages from their distribution to build Windows binaries. I'll
> > be happy to ALSO distribute the necessary instructions to make it easy
> > for people to build natively - as long as your changes don't break cross
> > compilation or any of the native builds.
> if someone is building opensource software all the time, he might have a nice
> pkg-config setup with .PC files on win32 (for such a user the default Makefile
> _should_ work), but as an alternative i was going to propose a separate
> "Makefile.win32nopkg" that can have the paths hardcoded for users that for
> example only need to build subsurface.
> my main reason behind this is that pkg-config does not make much sense on win32,
> unless one is using a package manager like in cygwin (but to my knowledge there
> isn't a default one for msys/mingw), or has all the needed .PC files, which he
> has to edit _manually_ in most cases.
> a "subsurface-libs-src.zip" can be provided for download (to be extracted in
> /c/libs/ ) and the user would build with:
> make -f Makefile.win32nopkg LIBPATH=/c/libs/
> i have an example here:
I'd rather have this in one Makefile that just works everywhere. We
already do some manual magic for libdivecomputer, I don't think it would
be all that hard to do have a conditional section that sets up the other
> btw i've downloaded all my libraries from the (gtk+), but it looks like i'm
> using different versions that yours.
My libraries come from the OpenSUSE cross compiled gtk2+ packages.
> if a zip "subsurface-libs-dll.zip" is also provided then it has to match the
> versions in "subsurface-libs-src.zip". e.g. i have "libxml2.dll" and
Not sure how to deal with that - in the subsurface.nsi file we need the
exact versions that we link against. Is there a tool like ldd on Windows
that we could use to create the output? All I found is DependencyWalker
and that's not a native tool, either (and not opensource, either, so we
can't distribute it).
More information about the subsurface