Since we ship it all in one piece there is no reason to use a static
libdivecomputer (like there is on Linux). This allows us to give the user
a different libdivecomputer.dll for testing when tracking down a bug.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems to fix our issues with being able to create zip files on the
fly (needed for the divelogs.de access).
Fixes#955
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While this should be fixed in cmake, for now just manuallt get
libssrfmarblewidget.dll and QtXml.dll in place
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instructions how to use it are in the script.
As of today this doesn't create working binaries - this worked perfectly
fine back when MXE was still based on Qt5.4
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The MinGW based script is still there for reference, but that's no
longer how I build the Windows binaries.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
We now have perfectly fine 32bit binaries with Qt5 so no more reason to
steer people towards 64bit binaries. Actually, I don't plan to make 64bit
binaries for the next release.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This script is based on the mxe package and builds everything from source
instead of using the mingw packages from Fedora as I did in the past.
I'm keeping the old script around for now, but eventually I should remove it as
this is the current way to create a working installer that supports both 32 and
64 bit Windows and is Qt5 based.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It makes more sense to do this on init and not have the user go through
any other screens in case this is the wrong binary.
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>
I assume the theme directory should be deleted on uninstall the same way
e.g. Documentation directory is deleted.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I was confused by the function name getSubsurfaceDataPath() - it does not
find paths relative to the "data" folder, if finds the path where we might
install folders like "data", "translations", or "theme".
"data" is for some reason where we install the "marbledata" files.
Therefore on both Mac and Windows we need to put the "theme" directory
next to the "data" directory, not below it.
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>
When doing an out of tree build you don't want to stage the package with
the source but under your current directory. So let's make sure we
distinguish between source and target here... and instead of putting
things into packaging/windows they now end up in staging which is much
more consistent. And to make my life even easier, the installer .exe ends
up in the base dir in which you build the package.
Also, we link statically against libdivecomputer, so don't pack the dll.
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>
This means we no longer need to keep them on disk and worry about
installing / uninstalling them. They will always be kept in-memory
(compressed).
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We appear to be missing the correct dll. I'm out of time trying to track
this down, so I just switched Subsurface to access divelogs.de via http on
Windwos.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
They are loaded into a Qt resource and always accessed via it.
[Dirk Hohndel: had to hand edit / apply the changes to the .pri file]
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Install the Documentation and include it in the installer.
Try and get all the directories and files removed in the uninstaller.
Where the heck does 'oldshare' come from?
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The executable shortcuts were lacking icons. This should
do the trick, by using the packaged subsurface.ico.
Perhaps it would be better if we hardcode the icon into
the executable as a resource.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And increase our list of plugins to be deployed to include the GIF and
SVG image plugins, the SVG icon engine and the CJK text codecs.
The install rules now iterate over the plugin list and deploy the
plugins in the right path in the staging area. The plugins must also
be scanned for dependencies (Fedora's qjpeg4.dll depends on
libjpeg-62.dll, which neds to be copied to the staging area).
Finally, fix qt.conf needed to be fixed.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
That way, the NSIS rules also work for creating an installer for debug
builds. Which you'd do by running:
make -f Makefile.Debug installer
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
My system has libzip-1.dll, but Dirk's is probably newer and has
libzip-2.dll
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The "make install" step will copy all we depend on DLLs there.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is seriously flawed. makensis is run twice for some reason. I also
noticed that the data and xslt directories under packaging/windows aren't
created when running make install. Running
make -f Makefile.Release install_marbledir install_deploy
works, but obviously this should be taken care of by the dependency.
The installed binary under Windows is not finding its icon, the
translations are missing... lots of work left to do here.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Marble doesn't work, yet (Google Maps aren't loaded), but at least
Subsurface starts under Windows with the installer built.
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>
On installation, set the "DisplayVersion" registry value
to ${SUBSURFACE_VERSION}, so that a version is displayed
when browsing the list of installed programs.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The NSIS script on installation will write a key to the registry
that will be shown to the user as a "Subsurface" entry (with icon)
in the list of installed programs that can be uninstalled
(e.g. in the Control Panel).
On uninstall, said registry key will be removed.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
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>
