Since we can build for more than one platform at the same time
now, it's userful to block them on the gitignore to make sure
we don't get a dirty tree just because we build for mobile
and desktop inside the subsurface folder.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Just added the missing files to the CMakesList.txt
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For modifications to the final source code of built android package
such as permission additions and inclusion of xml and java files, it
is necessary to maintain a template. The template is copied without
any modifications on top of qt android-template before building
subsurface libraries. Refer:
http://qt-project.org/doc/qt-5/deployment-android.html#qmake-variables
Files that are required to be directly copied to android package
would be included in directory android.
Icons for subsurface on android and string.xml are included.
Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Apparently qmake can't tell that #include "version.h" and #include
"libdivecomputer/version.h" are not the same thing. Instead of spending
another bunch of hours on fixing the buildsystem I decided to just cleanup
the spots where we actually use the version file and rename it to
ssrf-version.h.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Added rules on the gitignore file for ignoring the translations
that are generated during compile time.
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
This is working for me, but requires a bit more testing. To build,
run:
qmake [options]
Where options might be:
V=1 disable "silent" build
LIBDCDEVEL=1 use side-by-side libdivecomputer
INCLUDEPATH+=xxx add -Ixxx (e.g., INCLUDEPATH+=/usr/local/marble/include)
LIBS+=xxx add xxx to the linker flags (e.g. LIBS+=-L/usr/local/marble/lib)
or any other qmake option, including debug and release options
If your distribution is already using qtchooser in place of qmake, you
may need to pass an extra option to qmake to select the a
cross-build. For example:
qmake -qt=i686-w64-mingw32-qt4
If your distribution is not yet using qtchooser, then you need to file
a bug report requesting it and you need to run the full path to qmake.
Note:
- there are some ### left in the buildsystem
Signed-off-by: Thiago Macieira <thiago@macieira.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>
Qt Creator cannot import Subsurface directly because our buildsystem
is not any of the three that it understands (qmake, cmake,
autotools). So, instead, we can create the files Creator uses for
"Other Project" projects.
The files are:
- subsurface.config: the #defines from the command line (-D args)
- subsurface.creator: an XDG Desktop-style file with Creator settings
- subsurface.files: the list of source and header files
- subsurface.includes: the include paths (-I args)
They are also added to .gitignore, alongside the *.user file that
Creator uses to store per-user settings (editor configuration).
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
You may have noticed that running make is a little slow. Every time
that it is loaded, it will try to detect everything again. So,
instead, save the output and reload it the next time.
This is implemented by adding a rule that (re-)creates the
config.cache file, which is included by make. If the file doesn't
exist yet, make will first run the rule which creates it, then reload
itself.
You can also cause it to reconfigure by running "make configure".
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Setup the build variables for building with QtWidgets, and add rules for
processing the Q_OBJECT macros with moc and generate widget code from
.ui files with uic.
Signed-off-by: Alberto Mardegan <mardy@users.sourceforge.net>
This is dedicated to Lubomir ;)
Should work (tm). Not sure though if you want target
'gen_version_file' as a pre-requisite to $(NAME) or some other target.
[Dirk Hohndel: minor adjustments to make it work with gtk-gui.c]
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I never really liked 'diveclog' as a name - it's not like the C part is
all that important. And while I could try to just make up another slang
word for despicable person (in the tradition of naming all my projects
after myself), I just can't see it.
So let's just call it "subsurface".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's not called 'parse' any more. And I think I should rename 'divelog'
too to something more unique. Right now the working name for the
project is 'diveclog' (kind of like 'jdivelog') , but I'm not convinced
that the "C implementation" part is really important enough to make a
point of long-term.
"subsurface"? I don't know. Maybe I should follow the "name all
projects after myself" mantra. "divenut"?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
