Hi all, I investigated on RPM compression methods used to create the source and debug RPMs.
It appears that the default compression algorithm is LZMA, which is known to be efficient but rather slow. I made a test by forcing the compression method to gzip/level 1 in the crosswalk spec file and the results are interesting: * before: 1700s to assemble the source and debug RPMs * after: 70s That's just a x24 gain... Baptiste Durand will make a pull request for that. BR -- Stéphane Desneux Intel OTC - Vannes/FR gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726 On 18/09/2014 16:04, Raphael Kubo da Costa wrote: > Jean-Benoît MARTIN <jean-benoit.mar...@open.eurogiciel.org> writes: > >> I am working on Tizen project. >> In order to improve the build time of crosswalk, I would like to split >> crosswalk in several packages : >> - package with crosswalk source ( xwalk, xwalkctl, xwalk_launcher, >> xwalk-pkg-helper ) >> - several packages with thirdparty ( blink, skia , ...) >> >> In tizen project the build of crosswalk take time. Each time we modify >> a tizen package, crosswalk need to be rebuild. By separating packages >> we can build only necessary packages and not all crosswalk project. >> >> Currently I have made a workaround with 2 packages. >> https://review.tizen.org/git/?p=platform/framework/web/crosswalk.git;a=commit;h=b41067d2b9c6627c8e36a31fa4dc1051d4d91ff0 > > Hi Jean-Benoît, > > Splitting Crosswalk into separate packages like that is not a solution > we could adopt ourselves, at least not like in the form of the > workaround you linked to -- you're basically creating a tarball of the > build directory and reusing it in the other package. Even if you > "package" the untarballed files you're still just packaging a bunch of > .o and .a files. > > XWALK-2571 appears to provide more insight into the problems you guys > are having. Based on that, I have a few questions: > > * Isn't it possible to use incremental builds for at least some of your > build stages? We've been using those in our bots from the beginning > and it's been the only way to have minimally reasonable build times > for all patch submitted and committed to Crosswalk. > I think this would be particularly helpful for the case of having to > build Crosswalk due to changes in the librarys it depends on, for > example. > Note that our approach to incremental builds is different from passing > --incremental to "gbs build", though. > > * Given you guys have managed to build Crosswalk from scratch in 50min > with some powerful hardware, isn't it an option to use better hardware > in build.tizen.org? > > * Have you guys considered improving the tooling as well? Especially > in the situation where you're able to only build what really needs to > be built, there still are two big things that slow everything down: > - The /usr/lib/rpm/check-files script. > - The creation of the source RPM file. This, alone, took between 25 > and 30min in our most recent IVI and Common builds in > build.crosswalk-project.org. > I filed DEVT-193 a while ago to have someone fix this, but there's > been no activity in JIRA. Basically, if we're able to pass, say, > "-bc" or "-bb" to rpm it would help a lot with build times, for both > us as upstream and you guys working on tizen.org > _______________________________________________ > 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
