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>
The $(@D) (equivalent to $(dir $@)) tells us what the directory the
target is in. We could also have used the one for the source. They're
equivalent there.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
If you run
make V=1
Then we'll output the full command-line. It's useful for debugging
problems with the build.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
We use the -MG preprocessor option to the compiler to ask it to check
all #includes and tell us what's missing. Then our own rules will
generate the moc and uic files that the .cpp #include.
Unfortunately, our rules make uic generate output in qt-ui/ for
qt-ui/*.ui, while the compiler generates rules for no directory. We
need to fake it by forcing the generation.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Instead of listing objects, let's list sources. This matches also what
qmake and most other buildsystems do. The notable exception is the
kernel.
The reason that listing the sources will be interesting is because I'm
about to add rules to create the dependency files.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Similar to the qmake variable of the same name, this lists (at least)
the headers that may need moc to be run on. Adding more headers is not
a problem.
Signed-off-by: Thiago Macieira <thiago@macieira.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>
Configure.mk contains the detection rules, whereas Rules.mk contains
the rules to actually build Subsurface. This simplifies Makefile
greatly, which is the file that should be actually modified during
regular updates to the codebase.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
