Now that a few days have passed and nothing exploded, it's time to
announce commit da52b4060e684e7a432543b34fd91831ece48d89 to everyone who
was not following pull request #1127.
TL;DR:
- The need for having a separate flat git tree and for using the
generate-flat-tree.sh to build Tizen RPMs is no more.
- To preserve the build directory across Tizen builds, specify a build
directory outside /home/abuild/rpmbuild with the new BUILDDIR_NAME
macro and be happy. For example:
$ gbs build -A i586 --define 'BUILDDIR_NAME /tmp/crosswalk-build'
The long version:
We are now using a custom postexport git-buildpackage hook to call the
new packaging/gbp-flat-tree.sh script automatically when one calls "gbs
build". It is responsible for calling tar(1) and packaging all of
Crosswalk's source code. We do not need to do this manually by calling
"gclient recurse" and maintaining a separate git tree.
This has then paved the way for supporting Tizen incremental builds.
They were not working before for two reasons:
1. The RPM build area is erased every time "gbs build" is called
2. The files in the original source tarball generated by "gbs build"
calling "git archive" (and used in the RPM build) all have the mtime
of the commit passed to "git archive", so even files that did not
change between builds would have the wrong mtime and end up being
rebuilt.
To solve (1) we now allow one to specify a different build directory
that is outside the RPM build area that is erased, and (2) is solved by
calling tar and packaging the files ourselves with the right mtimes.
The experimental build bots in build.crosswalk-project.org are already
using incremental builds. The time for a GBS build went from around
50min to approximately 14min.
There are some obvious caveats that one should watch out for:
- We are essentially bypassing the git-buildpackage's archival process.
The very same things that allow us to create archives with proper
mtimes also package everything that is currently inside src/. In other
words, "gbs build" will work as if you _always_ pass "--include-all
--commit=HEAD" to it.
- You may end up triggering a full rebuild anyway if:
o Some problem happens in the `gbs build' call and the whole chroot
(not only the RPM build root) ends up being erased.
o You use `gbs chroot' to call `make' yourself, as a simple change in
the original CFLAGS or CXXFLAGS triggers a rebuild of all files.
o You change your source directory name for some reason. This is why
the generated source tarball does not contain a version number, for
example.
- Additionally, I don't claim any responsibility over
https://crosswalk-project.org/#wiki/development-on-tizen (that page
does need some love). If you are using weird chroot tricks with bind
mounts, you are supposed to know what you are doing.
There is still room for improvement. Out of those 14min it took to build
Crosswalk on Tizen, less than 6 were spent in the actual build process
(until the xwalk executable finished linking). All the other 8 minutes
were spent on RPM meta-stuff: checking for unpackaged files, creating
debuginfo and debugsource packages, extracting debug information from
the binaries etc. Improving that (or skipping some of those tasks
altogether) involves changing some Tizen tools themselves, which can
take some time.
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
