Hi all, Just let you know, I meet build issue as described in https://crosswalk-project.org/jira/browse/XWALK-359 , Raphael said Mrunal meet same issue also. It is unsure my environment issue or a bug.
Shiliu or myself will try to deploy tizen trybot to check. Thanks, Halton. > -----Original Message----- > From: Crosswalk-dev > [mailto:[email protected]] On Behalf Of > Poussa, Sakari > Sent: Tuesday, November 19, 2013 5:35 PM > To: Kubo Da Costa, Raphael; [email protected] > Subject: Re: [Crosswalk-dev] PSA: Improved support for incremental Tizen > builds > > 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" > <[email protected]> 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 > >[email protected] > >https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > > _______________________________________________ > Crosswalk-dev mailing list > [email protected] > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
