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>
- on uninstall, delete all XSLT files and the "$instdir\xslt" folder itself
- manage a desktop icon (i believe we had that before?)
- ignore SVG files, as we are now embedding them as static resources
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In preparation for a subsurface-icon.h, this should avoid confusion
about whether "subsurface.h" is a core header file.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
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 still requires on carefully staged files in the packaging/windows
directory. Specifically:
- the dll directory (or symlink) points to the installed gtk Windows DLLs
- the mydll directory (or symlink) contains six other DLLs (where the
cross built DLLs from Fedora for some reason file, but can be
transparently replaced with the ones from the upstream binary
package
- the share directory contains the Windows gtk locale files (but only for
the locales that we support, anyway)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
http://nsis.sourceforge.net/Docs/Chapter4.html#4.9.7.7:
"Sets the context of $SMPROGRAMS and other shell folders. If set
to 'current' (the default), the current user's shell folders are used.
If set to 'all', the 'all users' shell folder is used"
Specific to the Windows installer.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Removed redundant /oname settings when copying files. This is not required
since the file name is not changed.
Signed-off-by: Ivan Habunek <ivan.habunek@gmail.com>
Windows Vista and later require admin privileges to install to the Program
Files folder. Updated RequestExecutionLevel accordingly.
Signed-off-by: Ivan Habunek <ivan.habunek@gmail.com>
VIProductVersion requires to have the version number in x.x.x.x format
so I added a separate constant SUBSURFACE_VIPRODUCTVERSION for that
purpose. Also renamed VERSION to SUBSURFACE_VERSION for consistency.
As Lubomir suggested on the mailing list, the installer will now delete
any DLL files found in the target folder to prevent buildup of old
versions of libraries when upgrading subsurface.
Signed-Off-By: Ivan Habunek <ivan.habunek@gmail.com>
Cleaned up whitespace issues
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Forgot to add "Uninstall.exe" to the uninstaller section, so the file and
the installation folder weren't being deleted on uninstall.
Signed-Off-By: Ivan Habunek <ivan.habunek@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Also bumped version number to 1.2 (current release).
Signed-Off-By: Ivan Habunek <ivan.habunek@gmail.com>
More whitespace cleanup
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The existing windows installer looks very archaic and offers very few
configuration options. This script offers the following benefits:
* A modern appearence using NSIS Modern UI 2.0
* Shows the GPL license before install
* User can choose the target install folder
* Stores chosen installation folder in registry
* When installing a newer version on top of existing one, the existing
installation folder is offered by default
* It is possible to opt out of creating start menu shortcuts
Additional bug fixes:
* Added iconv.dll which was missing from the installer
* Replaced all path separators with backwars slashes, so that the script
works on both linux and windows
Signed-Off-By: Ivan Habunek <ivan.habunek@gmail.com>
Cleaned up whitespace
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add missing files and update a library version number.
The library version thing seems to indicate that this is much more fragile
than I'd want it to be...
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>
a yes/no dialog to clear or store data in HKCU "SOFTWARE\subsurface"
"Do you wish to store subsurface's settings?"
fixed small whitespace issue
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
These need more work but I'd rather have them here under version control.
The spec file appears to successfully build the Windows binaries, given
the right tar file to start with. Those binaries are then packed into an
rpm file (extermely useless to Windows users).
Once the rpm is unpacked one can then use the NSIS compiler and the .nsi
file to create a Windows installer. This all is still extremely fragile,
but it worked at least once...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With this we are able to include both a separate .ico file that the
program can load at runtime and a .res file (that is created from the .rc
file, both in the packaging/windows directory) that is linked into the
executable and makes the Windows Explorer show the correct icon for
subsurface.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
