Split crosswalk build in 2 packages #2575
Conversation
|
Testing patch series with eurogiciel-oss/crosswalk@d41d784 as its head.
|
jbtrek
force-pushed
the
split_crosswalk
branch
from
d41d784
to
4724feb
Compare
|
Testing patch series with eurogiciel-oss/crosswalk@4724feb as its head.
|
|
There is issue with the patch. I will push an update of the patch soon |
|
Has anyone tried using |
jbtrek
force-pushed
the
split_crosswalk
branch
from
4724feb
to
b9300a5
Compare
|
Testing patch series with eurogiciel-oss/crosswalk@b9300a5 as its head.
|
|
We have try to use "src/build/linux/unbundle/*" for some third-party libraries but it was not effective enough. |
|
Would the efforts of moving part of our Tizen code to tizen.org help in anyway? As I said before, this current approach basically goes against every packaging standard by introducing a very ugly hack that can break in many ways. I've never heard of anyone packaging a build directory for consumption for another RPM package to continue from there. |
|
@rakuco : If you don't agree to include this (we can understand that as we know that split is a hack), but what is your proposition? we want a solution |
jbtrek
force-pushed
the
split_crosswalk
branch
from
b9300a5
to
150cf46
Compare
|
Testing patch series with eurogiciel-oss/crosswalk@150cf46 as its head.
|
jbtrek
force-pushed
the
split_crosswalk
branch
from
150cf46
to
ae96d3d
Compare
|
Testing patch series with eurogiciel-oss/crosswalk@ae96d3d as its head.
|
crosswalk.spec : build thirdparty crosswalk-bin.spec : build binaries xwalk, ... Workaround to decrease the build time of crosswalk Most of crosswalk thirdparties are built separately BUG=XWALK-2571 Signed-off-by: Jean-Benoit MARTIN <[email protected]>
|
Is building with |
|
good idea but I thinks you forgot 1 important thing. One Tizen there is a multiple packages that can be found also as Thirdparty of chromium. I detail an example We have a Mesa package in Tizen Build Third party of Chromium in shared library leads to have two differents version of Mesa both in shared library. When there is two libraries in the system we need to take care about which ones should be used for which binary. Build statically can permits to avoid this problem. An other exapmle is sqlite3 the crosswalk/chromium has new API that not exist upstream.... |
|
Hence my question -- if packaging static libraries is accepted in Tizen, we could have a crosswalk-libs package with .a files, and maybe install them in a different location, or with a different name. |
|
@rakuco : please try your proposal and submit a PR associated. |
|
@rakuco |
|
Nope, it shouldn't be a problem. All shared libraries will be installed into |
|
So what is the point of this? To expose whole crosswalk-thirdparty as one pkgconfig package or several libraries from chromium's src/ directory as seperate packages? Is there needed more than one .pc file? Do anyone needs to know what different versions of libraries are inside crosswalk (as there are different and will conflict if installed normally)? I basicly wonder if there is possibility to export as devel package chromium's headers and single static/shared library with one .pc file? Or is it wrong approach? |
|
The point of what exactly? The point of this pull request (which is not going to be merged) is to work around the fact that Crosswalk is a big package. What I am working on separately and will submit in another pull request is a split between crosswalk-libs and crosswalk-bin, with libs containing all necessary shared libraries after switching the build to |
|
Oh, sorry for misunderstanding. I probably did not get the point. What crosswalk-libs will provide for crosswalk-bin? Only .so files? |
|
Yes. Only private .so's required for building and running Crosswalk. It's one big hack that people have been pushing for for ages. |
crosswalk.spec : build thirdparty
crosswalk-bin.spec : build binaries xwalk, ...
Workaround to decrease the build time of crosswalk
Most of crosswalk thirdparties are built separately
BUG=XWALK-2571
Signed-off-by: Jean-Benoit MARTIN [email protected]