Raphael, Is there a way to just use make if you donĀ¹t want the full rpm but just the xwalk binary? That is, to skip the dance around the rpm creation.
If so, that should be documented in the packaging/README and later in the wiki. BR; Sakari On 11/18/13, 17:53, "Raphael Kubo da Costa" <raphael.kubo.da.co...@intel.com> wrote: >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 _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev