summaryrefslogtreecommitdiffstats
path: root/README
blob: 7f3a86f9e16391c5c1e37520fbc43719d2424371 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
This directory contains the Qt3D project for Qt5:
   * QtQuick3D QML bindings and
   * Qt3D C++ APIs


Building QtQuick3D
==================

Qt5 is a rapidly changing bleeding edge environment.  This branch is our initial
support for it and thus is also rapidly changing and bleeding edge.

This branch is experimental, and unsupported.  This information is provided for
advanced use only.

No guarantees about API stability or even if this works at all are supplied, use
at your own risk.

First fetch the Qt5 source tree and QtQuick3D qml2 branch:

    cd ~/depot
    git clone ssh://codereview.qt-project.org:29418/qt/qt5.git
    cd qt5
    ./init-repository --codereview-username <username> \
        --module-subset=qtbase,qtsvg,qtdeclarative,qtscript,qttools,qtxmlpatterns,qtdoc,qlalr,qtrepotools,qtqa,qtlocation,qtquick3d
    git submodule foreach "git fetch gerrit && git reset --hard gerrit/master"
    cd qtquick3d
    scp -p -P 29418 codereview.qt-project.org:hooks/commit-msg .git/hooks/
    git fetch gerrit
    git checkout --track -b qml2 gerrit/qml2

If you are reading this file then somehow you probably already got this far anyway.

Now build Qt5, which will also build QtQuick3D as a module:

    cd ~/build
    mkdir qt5
    cd qt5
    ~/depot/qt5/configure -nokia-developer -no-webkit -no-phonon -nomake tests \
        -nomake demos -nomake examples -declarative -opengl -script -svg && make -j 4


Whats in QtQuick3D
==================

Directory structure:

src/threed/
    This is the main library of the Qt3D project, containing abstractions
    for cross-platform GL, shaders, lighting models, and so on.
src/plugins/
    Scene format loading plugins.
src/imports/
    QML import plugins.
util/
    Various utilities that are useful when working with Qt3D.
examples/
    Some examples of using QtQuiick3D (QML bindings) and Qt3D (C++ API).
demos/
    Some more complex demos of using QtQuiick3D (QML bindings) and Qt3D (C++ API).
tests/auto/qml3d/
    Unit tests for the QtQuick3D bindings.
tests/auto/threed/
    Unit tests for the Qt3D C++ API
doc/
    Documentation.
devices/symbian/
    Symbian deployment file


Documentation
=============

The documentation can be generated with "make docs".  It will be placed
into "doc/html" in the build directory.


Packages
========

This section is only for those developing QtQuick3D.  Read on to discover how
the building of packages works.  This section is also important if you want to
change how the structure of the QtQuick3D pro files work.

QtQuick3D is intended to be built in one of two ways:

1) Normal developer way:
        qmake && make
2) Package creation way:
        qmake CONFIG+=package && INSTALL_ROOT=tmp make install

In 1) the .pro files will cause the toolchain to place the libraries, plugins
header files and other components of QtQuick3D directly into place, as part of
the compile process.  What does "in place" mean?  Run "qmake -query" to see
the paths where the files are placed - QML plugins go in $$[QT_INSTALL_IMPORTS]
for example.  In this mode, there is no need to run "make install" because the
files are already in their target destination.  Here the "target destination"
means the Qt which is being built against.

First note that QtQuick3D has to be installed into the target Qt.  This is because
QtQuick3D has QML plugins and resources, as well as shared libraries, all of which
must be resolved by the QMLViewer of the target Qt at runtime.  Here where "qmake"
is referred to it means the qmake inside the target Qt.  Since QtDeclarative
recommends using QMLViewer when developing and debugging QML Apps, in the developer
case - which is what Qt3D is for - it has to install directly into the target Qt.

In this mode 1) after the main library is compiled subsequent targets can simply
resolve includes and link time dependencies by use of qt3d.prf and qtquick3d.prf.
These two files are installed into the target Qt's makespecs/features directory
during the processing of the quick3d.pro file.

In 2) the libraries, plugins and so on are sitting inside the build tree after
the compile step.  As a result in order to resolve includes and dependencies
the build system has to navigate the build tree with paths like "-L../../../threed"
to locate the Qt3D libraries.

Actually there is one build artifact that is not just left where it lands in the
build tree - the header files.  These are actually copied into an "include"
directory inside the build root directory.  This is because at present the header
files all live inside their own seperate subdirectories under "threed" and would
be too cumbersome to path in explicitly.

After building the tree the install step is invoked using the INSTALL_ROOT environment
export to cause the installation rules to place all the files into a sandboxed
install tree, ready for packaging.