Pull request Compare This branch is 15 commits ahead, 4675 commits behind crosswalk-project:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
..
Failed to load latest commit information.
Blink-Fix-gcc-4.5.3-uninitialized-warnings.patch
Chromium-Fix-gcc-4.5.3-uninitialized-warnings.patch
OWNERS
README
crosswalk-2.31-enable-VAVDA-with-EGL.patch
crosswalk-disable-ffmpeg-pragmas.patch
crosswalk-do-not-look-for-gtk2-when-using-aura.patch
crosswalk-include-tizen-ime-files.patch
crosswalk-look-for-pvr-libGLESv2.so.patch
crosswalk-tizen-audio-session-manager.patch
crosswalk.manifest
crosswalk.png
crosswalk.spec
crosswalk.xml.in
gbp-flat-tree.sh
generate-flat-tree.sh
install_into_pkginfo_db.py
xwalk

README

This directory contains a collection of tools and RPM-related files used to
build Crosswalk RPMs for Tizen.

BUILD INSTRUCTIONS
------------------

In the simplest case, a call to `gbs build' from the xwalk/ directory suffices.
It should create a Tizen chroot and launch a build from there, requiring no
further interaction and producing a few RPMs at the end of the process.

For more information on which other parameters one is normally expected to pass
to `gbs build' (including "-A" to specify the Tizen architecture) and also on
gbs' configuration file, please consult gbs' documentation.

A very important thing to notice is that, due to the way the integration with
gbs is implemented, _anything_ currently present in your source tree will be
built, regardless of whether "--include-all" is passed to `gbs build' or not.

INCREMENTAL BUILDS
------------------

By default, Crosswalk is built inside src/out/Release inside the Chromium's
directory. Also by default, each call to `gbs build' will erase the RPM build
root in the Tizen chroot, which means your previous build will be lost.

To avoid that, you need to specify a different build directory, one located
outside the build root. The new directory should be passed as a macro called
BUILDDIR_NAME:

  $ cd /path/to/src/xwalk
  $ gbs build -A i586 --define 'BUILDDIR_NAME /var/tmp/xwalk-build'

  (Note `/var/tmp/xwalk-build` is still a directory inside the chroot, so to
  the host system this is actually something like
  `/home/user/GBSROOT/local/BUILD-ROOTS/scratch.i586.0/var/tmp/xwalk-build`).

In case the build gets broken somehow, one can then just remove whatever is
faulty in the build directory (or the whole directory).

It is important to note that depending on what the .spec file looks like, an
incremental build may still rebuild some files even if nothing has changed: for
example, if patches are applied as part of the %prep stage and they modify some
source files, these ones will always be rebuilt.

This method is not completely fail-proof, though, and a full rebuild may end up
being triggered if:

- Some problem happens in the `gbs build' call and the whole chroot (not only
  the RPM build root) ends up being erased.

- You use `gbs chroot' to call `make' yourself, as a simple change in the
  original CFLAGS or CXXFLAGS triggers a rebuild of all files.

- You change your source directory name for some reason. This is why
  the generated source tarball does not contain a version number, for
  example.

FURTHER DETAILS
---------------

gbs, the tool used to generate RPM packages for Tizen, expects a single git
tree with all the necessary sources available so that it can run `git archive',
produce a tarball, extract it into a chroot and build from there.

Crosswalk, on the other hand, is made of many independent git and Subversion
repositories put together in a single directory structure. Additionally,
Crosswalk is checked out as a subdirectory of Chromium itself. This all is
unusual and does not work with gbs by default.

The whole problem is worked around by having using git-buildpackage's hooks
mechanism: the original tarball generated by git-buildpackage's call to `git
archive' is replaced by a new one generated with the gbp-flat-tree.sh script
located in packaging/. This new tarball contains everything in src/, except for
a few files we exclude by default (version control files and directories, for
example).

The gbp-flat-tree.sh script also helps us with incremental builds: since the
new tarball is generated with `tar' itself, all the files in the archive have
their correct mtimes (which is not the case with `git archive'). This, together
with an external build directory, allows one to avoid rebuilding all files
every time, since the source files with the right modification times _and_ the
build directory are preserved across builds.

THE DEPRECATED METHOD
---------------------

Before gbp-flat-tree.sh was introduced, building Tizen RPMs relied on the
`generate-flat-tree.sh' script. The whole process does not support incremental
builds, and requires creating a separate git tree that is then used by `gbs
build'. For reference, these are the instructions for building Tizen packages
this way:

 1. Have a single .gclient file containing entries for crosswalk,
    chromium-crosswalk and whatever may be needed. Something like this:

    solutions = [
      {'custom_deps':
        {'src': 'ssh://git@github.com/otcshare/chromium-crosswalk.git@9341417b1591282e02a4d3da0ece84496cb6999a',
         'src/chrome/tools/test/reference_build/chrome_linux': None,
         'src/chrome/tools/test/reference_build/chrome_mac': None,
         'src/chrome/tools/test/reference_build/chrome_win': None,
         'src/chrome_frame/tools/test/reference_build/chrome_win': None,
         'src/content/test/data/layout_tests/LayoutTests': None,
         'src/third_party/WebKit': 'ssh://git@github.com/otcshare/blink-crosswalk.git@abfee977cd60a915a094f247ff81f9d17dc85efe',
         'src/third_party/WebKit/LayoutTests': None,
         'src/third_party/hunspell_dictionaries': None,
         'src/webkit/data/layout_tests/LayoutTests': None},
       'name': '28.0.1500.36',
       'url': 'http://src.chromium.org/svn/releases/28.0.1500.36'},
      {"name"        : "src/xwalk",
       "url"         : "ssh://git@github.com/otcshare/crosswalk.git@origin/master",
       "deps_file"   : "DEPS",
       "managed"     : True,
       "custom_deps" : {},
       "safesync_url": ""},
    ]

    The specific values there do not matter, the point is that there should not
    be more than one .gclient file, so that `gclient recurse' can find all
    repositories.

 2. Generate a flat directory tree with the `generate-flat-tree.sh' script.

    $ export XWALK_PREFIX=/root/of/xwalk/tree
    $ gclient recurse --no-progress -j 1 path-to/generate-flat-tree.sh

    XWALK_PREFIX should point to the top-level directory of the tree (the one
    which _contains_ the src/ directory).

    Passing -j 1 to `gclient recurse' is very important, otherwise multiple
    jobs will try to write to the same tar file in parallel.

 3. Extract the generated tarball (flat-xwalk-tree.tar) somewhere, and put this
    directory (packaging/) in it.

    $ mkdir my-rpm-tree
    $ cd my-rpm-tree
    $ tar -xf /path/to/flat-xwalk-tree.tar
    $ cp -R /the/path/to/packaging .

 4. Create a git repository with the newly-extracted flat tree and commit.
    $ cd my-rpm-tree
    $ git init
    $ git add .
    $ git commit -m 'Initial commit'

 5. Run gbs as usual.
    $ gbs build -A i586