HINTS should be dynamically introspected, static entries should be in PATHS.
There is also a platform dependent list of things where CMake always looks if
not explicitely forbidden, so remove any entries that are usually in those
default lists.
Signed-off-by: Rolf Eike Beer <eike@sf-mail.de>
Printing never worked, none of this was ever included in test builds. Also, now
that there are official releases of QtWebKit again, this just doesn't seem worth
carrying along anymore.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On LGTM we end up installing in /opt/out.
Also, fix a silly error in the existing code - don't look for libraries in
include directories.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Apple app store rules prevent even testing a binary with the same version as one
that has been submitted for release.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Apple typically forces a much more detailed review if the version number
changes. Let's get this taken care of now as we prepare for release.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fully unsure when this got broken, but we tried to find the
libdivecomputer includes based on the include file "hw.h".
Interestingly, that file does not exisist (any more?) in
libdivecomputer, so the search for the include fails. This
is annoying, as the initial cmake fails on this in case of
developer builds from QtCreator (which do not compile all
dependencies like our home grown build scripts).
The solution is simple: just find the includes for
libdivecomputer based on exiting files in this lib.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The utility could be used for other targets,
path should therefore depend on the inputted target parameter
Signed-off-by: Jeremie Guichard <djebrest@gmail.com>
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>
