Update the documentation with dependencies for cross-building on Linux
to Windows for OpenSuse platform and correct some building instructions.
Moreover fix the windows building script to use the architectural specific
binary.
Signed-off-by: Claudiu Olteanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Checking this in to make sure I don't end up creating broken installers
again. I doubt that this is useful for anyone but me - but then, I don't
think anyone but me creates Windows installers.
Background - when Fedora 20 updated the cross-built version of Qt for
Win64 something broke. Subsurfae installed with those DLLs will crash.
Replacing the older 5.3.1 DLLs fixes this for now, so I have a directory
with just those DLLs and simply replace them in the staging directory
before calling makensis.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With these changes we link statically against libusb and libdivecomputer
but don't add the .a files to our installers.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This also makes sure that we package the Qt5 translations, not the Qt4
translations.
There was an odd issue that somehow a 32bit search path ended up being
used by win-dll which resulted in the wrong DLLs being packaged.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Admittedly I believe I'm the only one using this script (and related .nsi
file), it still seems to make sense to keep it up to date in the
repository.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is all mostly to make my life easier.
I'm not thrilled with the marble changes - as Linus pointed out before the
way we do these "LIBxxxDEVEL" changes is broken as it will still first
link against any library installed in the system. But since I have removed
any globally installed copies of these libraries this actually works for
me and it does help when experimenting with different build options for
the main libraries that we depend on.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way I can have a different directory from where I build Windows
binary without interfering with my native build in the source directory.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
After the 3.1 release it is time to shift the focus on the Qt effort - and
the best way to do this is to merge the changes in the Qt branch into
master.
Linus was extremely nice and did a merge for me. I decided to do my own
merge instead (which by accident actually based on a different version of
the Qt branch) and then used his merge to double check what I was doing.
I resolved a few things differently but overall what we did was very much
the same (and I say this with pride since Linus is a professional git
merger)
Here's his merge commit message:
This is a rough and tumble merge of the Qt branch into 'master',
trying to sort out the conflicts as best as I could.
There were two major kinds of conflicts:
- the Makefile changes, in particular the split of the single
Makefile into Rules.mk and Configure.mk, along with the obvious Qt
build changes themselves.
Those changes conflicted with some of the updates done in mainline
wrt "release" targets and some helper macros ($(NAME) etc).
Resolved by largely taking the Qt branch versions, and then editing
in the most obvious parts of the Makefile updates from mainline.
NOTE! The script/get_version shell script was made to just fail
silently on not finding a git repository, which avoided having to
take some particularly ugly Makefile changes.
- Various random updates in mainline to support things like dive tags.
The conflicts were mainly to the gtk GUI parts, which obviously
looked different afterwards. I fixed things up to look like the
newer code, but since the gtk files themselves are actually dead in
the Qt branch, this is largely irrelevant.
NOTE! This does *NOT* introduce the equivalent Qt functionality.
The fields are there in the code now, but there's no Qt UI for the
whole dive tag stuff etc.
This seems to compile for me (although I have to force
"QMAKE=qmake-qt4" on f19), and results in a Linux binary that seems to
work, but it is otherwise largely untested.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
commit 59294029f3d1 ("Capitalize package name and add capitalized tar-ball
prefix") had an unintended side effect: the cross build for Windows on
Linux no longer worked (as it set NAME=subsurface.exe).
Fixed this by introducing a TARGET variable that is derived from $(NAME).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a Makefile target to create the .nsi file from a template and to
hopefully create the right strings to magically get the correct version
strings in the Windows installer
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
[the macos/macosx typo was also found and a patch submitted by
Henrik Brautaset Aronsen <subsurface@henrik.synth.no>]
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This commit adds an install-cross-windows target to the Makefile that
creates a staging directory for us under packaging/windows that contains
the required .mo files. This currently fails for the Norwegian translation
because of the no_NO.UTF-8 vs nb issue - right now we just use the first
component of our own localization filename to find the matching Windows
localization and that fails.
The subsurface.nsi file is updated accordingly and this now appears to
create working installers with sane paths for the localization files.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This now works with a straight out of the box MinGW install on OpenSUSE.
A simple shell script that shows how to invoke the cross build is
included.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
