* only build a static libdivecomputer
* only build the libgit2 library, not the executable
* don't echo all the symlinks when fake-installing libmarblewidget
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This now assumes that a running changelog is maintained in
src/debian.changelog, i.e., at the same level as the subsurface tree; the
organization now should look like this:
src/debian.changelog
src/subsurface # subsurface git checkout
src/subsurface/libdivecomputer # libdivecomputer git Subsurface-xx branch
src/subsurface/marble-source # marble git Subsurface-xx branch
src/subsurface/libgit2 # libgit2 git checkout
Instead of running dh_make to create all new debian build files, we add the
necessary files in our script.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since we strip the .git data from the source tree (to conserve space and not
violate the packaging guidelines - or at least not violate THAT packaging
guideline) we need to create the correct revision before the tar file of sources
is packaged.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Marble can't be static, so instead we build a shared library but give it a
different name so it can be installed in parallel with the "real"
libmarblewidget.so.
Also make sure that the correct libusb is installed so that Atomics Aquatics
dive computers are supported.
Fixes#782
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Oops, I thought I had done that but that was flat out wrong.
Now the source upload shrinks from over 70MB to around 26MB. Much better.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
These files knowingly (one might say, intentionally) violate the spirit
and letter of the Debian / Ubuntu packaging rules. They are intended to be
able to create our own packages that include their own libdivecomputer,
libgit2 and (later) libmarble. Especially for daily builds this is WAY
easier than fighting with whatever may be the current version of these
packages in Ubuntu (especially since this allows us to use our private
libdivecomputer branch).
This assumes that the user runs the make-package.sh script from a
directory below which we have
subsurface/ <- Subsurface checked out git tree
subsurface/libdivecomputer <- desired libdivecomputer sources
subsurface/libgit2 <- desired libgit2 source
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>
The bundle signature is not a necessary property in any of the OS X
versions we support. And the current bundle version identifier is 6.0,
not 1.0.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is required to enable HiDPI support for the Retina displays. The
Info.plist that comes with Qt had this, but the one we supply with
Subsurface didn't.
Done-with: Jake Petroules <jake.petroules@petroules.com>
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On one of my machines codesign doesn't find my signing key by hash, but
does find it by name. Go figure.
Also on that same system (32bit Mac Mini with running Snow Leopard / 10.6)
gcc 4.2 doesn't support the -unused-result warning. So let's only turn
that on for more modern versions of gcc
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>
These are only useful for me, but having them in git makes my life so much
easier...
Instead of using macdeployqt to create my DMG I use the tool that I used for
Subsurface 3. This allows for much prettier DMG content as well.
Fixes#329
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>
