Right now this is only designed for Linux where current distros all should have
a new enough libgit2 (and our instructions tell people to install this with
system tools, so we should also use it).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This removes all references to WebKit if cmake option USE_WEBKIT is enabled.
For the user manual it changes it to WebEngine (seems to work for me).
Similar for the Facebook connection (minus a reference to a cookie jar).
This I could not test at the moment, as I wrote this on a train.
Printing does not work, it is a null operation at the moment. Currently,
large parts of of the printing code are commented out as there is no direct
way to access page elements in WebEngine. It seems this needs to be done
via Javascript (with a callback invoked). There is new functionality in
WebEngine to render a view to a PDF file but this needs more work (and
probably some thoughts towards page breaks).
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Just so that the iOS release has a sane starting point - and frankly,
we've done a very poor job of maintaining this version number.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Even though 1.0.0 was never released publicly, it was offered to beta
testers, so it is good practice to bump the version number for the next
binary that I'll push to them. Even if the build number would of course be
different.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And make sure the version displayed for Android includes both that version
and the build version, which is our regular canonical 4 part version
number - so this release will be something like "1.0.0 (4.5.2.1047)"
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is hard coded in version.cmake for now. The intent is to go to 1.0 in
the first release version and to increment from there whenever we create
an update.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It no longer makes sense to lie about the version. If you are running a product
build, then the canonical version is the same version as the plain version used
to be. And in either case it makes much more sense to simply log the full
version information.
We used to have the differently styled versions for different OSs, but I don't
think this is needed anymore. Let's hope this doesn't go down as one of these
"famous last words" moments...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This shouldn't hurt on any platform, but it may help on a couple of
platforms where it appears we are missing libcrypto on the link line.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
More issues with the static cmake files. Again we were missing a variable
and needed less quoting. Additionally there was dead / redundant code.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Because of this a bunch of variables need to be passed in and the quoting
changes in rather subtle ways.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I don't know why on one of my Macs (running El Capitan, XCode 7.2, cmake 3.4.1)
I get Libssh2_FOUND instead of LIBSSH2_FOUND, but this hack works around the
problem.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is actually a good change: we used to write a new
CMake file in configure time just to move it outside of the
source to the build dir at compile time. Now this file is
pre-created and it's only moved.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
In source builds creates a lot of noise on the source tree,
creating tons of temporaries that makes git status cry, and it also
creates dangerous files that have names similar to actual source
and could make a developer use them by mistake.
Make out of source buiild mandatory to remove that, it also makes
CMake code easier to read.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
CMake is a strange and complex language for buildsystems,
and as such we need to let the main CMakeLists.txt be as
clear as possible.
Moving a bunch of code that deals with finding git via
default CMake way or pkg_cofig to a file named 'HandleFindGit'
on our cmake/Modules folder.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
And use this to look for libusb.
If it's there then libdivecomputer likely was linked against it. If it isn't
then we don't need it, either.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems less confusing then calling it just "install".
Also adjust our cmake/Modules/Find... files accordingly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It currently searches for the .a (preferred) or the .so in the following
directories, in order: ${CMAKE_CURRENT_SOURCE_DIR}/../libgit2, /usr/local,
and /usr.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now we search for Marble in the default build folder, too, which is
CMAKE_CURRENT_SOURCE_DIR/..
Also look for both regular Marble and for our Subsurface branch of Marble
(which uses a different library name).
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The pkg_config_library macro is a helper macro and was generating noise
on the main CMakeLists.txt file, so I moved it to another file.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is the correct way to deal with CMake Modules (or at least, the
default way). All our custom CMakeFiles will be here.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
