third_party: Add wayland library.

third_party: Add wayland library.

This adds the wayland library to third_party and libffi
as a build dependency on linux. libffi is already a run-time
dependency as libgobject depends on it.

BUG=549782
Committed: https://crrev.com/754ca2c474484f29b3b33c1d2f1909c6a3193260
Cr-Commit-Position: refs/heads/master@{#359701}

[reveman, 2015-10-31 00:33:58]

reveman@chromium.org changed reviewers:
+ ben@chromium.org, piman@chromium.org

[piman, 2015-10-31 01:47:55]

lgtm

[Ben Goodger (Google), 2015-10-31 03:44:05]

lgtm2

[reveman, 2015-11-08 03:16:09]

The CQ bit was checked by reveman@chromium.org

[reveman, 2015-11-08 03:16:10]

The patchset sent to the CQ was uploaded after l-g-t-m from piman@chromium.org
Link to the patchset: https://codereview.chromium.org/1426583009/#ps60001
(title: "update urls")

[commit-bot: I haz the power, 2015-11-08 03:16:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1426583009/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1426583009/60001

[commit-bot: I haz the power, 2015-11-08 04:00:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-08 04:00:50]

Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[reveman, 2015-11-08 05:36:46]

The CQ bit was checked by reveman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-11-08 05:36:53]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1426583009/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1426583009/80001

[commit-bot: I haz the power, 2015-11-08 06:57:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-08 06:57:46]

Dry run: This issue passed the CQ dry run.

[reveman, 2015-11-08 23:42:21]

Description was changed from

==========
third_party: Add wayland library.

This adds the wayland library and the libffi dependency to
third_party. Build configurations are limited to x86_64 for
now but support for additional platforms will be added in
follow up patches.

BUG=549782
==========

to

==========
third_party: Add wayland library.

This adds the wayland library to third_party and libffi
as a build dependency on linux.

BUG=549782
==========

[reveman, 2015-11-09 00:24:45]

Description was changed from

==========
third_party: Add wayland library.

This adds the wayland library to third_party and libffi
as a build dependency on linux.

BUG=549782
==========

to

==========
third_party: Add wayland library.

This adds the wayland library to third_party and libffi
as a build dependency on linux. libffi is already a run-time
dependency as libgobject depends on it.

BUG=549782
==========

[reveman, 2015-11-09 13:31:12]

reveman@chromium.org changed reviewers:
+ thakis@chromium.org, thestig@chromium.org

[reveman, 2015-11-09 13:31:12]

+thakis for build/, how do I add new build dep and have the bots actually
install them? they all seem to be failing now as they are not running
install-build-deps.sh

+thestig for tools/checklicenses/checklicense.py

[Nico, 2015-11-09 17:01:45]

On 2015/11/09 13:31:12, reveman wrote:
> +thakis for build/, how do I add new build dep and have the bots actually
> install them? they all seem to be failing now as they are not running
> install-build-deps.sh

thestig, do you know this? I guess one has to file an infra ticket to rerun the
scrit everywhere?

> 
> +thestig for tools/checklicenses/checklicense.py

[Lei Zhang, 2015-11-09 17:41:28]

https://codereview.chromium.org/1426583009/diff/120001/third_party/wayland/OW...
File third_party/wayland/OWNERS (right):

https://codereview.chromium.org/1426583009/diff/120001/third_party/wayland/OW...
third_party/wayland/OWNERS:1: reveman@chromium.org
add a backup owner?

https://codereview.chromium.org/1426583009/diff/120001/third_party/wayland/in...
File third_party/wayland/include/protocol/wayland-client-protocol.h (right):

https://codereview.chromium.org/1426583009/diff/120001/third_party/wayland/in...
third_party/wayland/include/protocol/wayland-client-protocol.h:1: /*
Why are some headers checked in while others are pulled in via DEPS?

https://codereview.chromium.org/1426583009/diff/120001/tools/checklicenses/ch...
File tools/checklicenses/checklicenses.py (right):

https://codereview.chromium.org/1426583009/diff/120001/tools/checklicenses/ch...
tools/checklicenses/checklicenses.py:559: # MIT license but some files contain
no licensing info. e.g. autogen.sh.
Can you file a bug for third_party/wayland not passing check_licenses?

[Lei Zhang, 2015-11-09 17:42:31]

On 2015/11/09 17:01:45, Nico wrote:
> On 2015/11/09 13:31:12, reveman wrote:
> > +thakis for build/, how do I add new build dep and have the bots actually
> > install them? they all seem to be failing now as they are not running
> > install-build-deps.sh
> 
> thestig, do you know this? I guess one has to file an infra ticket to rerun
the
> scrit everywhere?

Check in the install-build-deps.sh changes in a separate CL first. Then file a
bug to ask Infra to run it and install the new build deps, before coming back to
this CL.

[reveman, 2015-11-09 19:28:05]

On 2015/11/09 at 17:42:31, thestig wrote:
> On 2015/11/09 17:01:45, Nico wrote:
> > On 2015/11/09 13:31:12, reveman wrote:
> > > +thakis for build/, how do I add new build dep and have the bots actually
> > > install them? they all seem to be failing now as they are not running
> > > install-build-deps.sh
> > 
> > thestig, do you know this? I guess one has to file an infra ticket to rerun
the
> > scrit everywhere?
> 
> Check in the install-build-deps.sh changes in a separate CL first. Then file a
bug to ask Infra to run it and install the new build deps, before coming back to
this CL.

Thanks. Created https://codereview.chromium.org/1410093009 for this.

https://codereview.chromium.org/1426583009/diff/120001/third_party/wayland/OW...
File third_party/wayland/OWNERS (right):

https://codereview.chromium.org/1426583009/diff/120001/third_party/wayland/OW...
third_party/wayland/OWNERS:1: reveman@chromium.org
On 2015/11/09 at 17:41:28, Lei Zhang wrote:
> add a backup owner?

added piman as backup

https://codereview.chromium.org/1426583009/diff/120001/third_party/wayland/in...
File third_party/wayland/include/protocol/wayland-client-protocol.h (right):

https://codereview.chromium.org/1426583009/diff/120001/third_party/wayland/in...
third_party/wayland/include/protocol/wayland-client-protocol.h:1: /*
On 2015/11/09 at 17:41:28, Lei Zhang wrote:
> Why are some headers checked in while others are pulled in via DEPS?

The headers that are checked in are all automatically generated and not part of
the source being pulled in via DEPS. Generating these protocol headers as part
of the chromium build would require wayland-scanner to be installed on the host
which is non-trivial to add as a build dependency on chromeos.

README.chromium includes instructions for how to check in new versions of these
headers when updating the package. Same is needed for config.h anyhow.

[Lei Zhang, 2015-11-09 19:34:19]

On 2015/11/09 19:28:05, reveman wrote:
> added piman as backup

You can add # comments to indicate this, if desired.

> The headers that are checked in are all automatically generated and not part
of
> the source being pulled in via DEPS. Generating these protocol headers as part
> of the chromium build would require wayland-scanner to be installed on the
host
> which is non-trivial to add as a build dependency on chromeos.
> 
> README.chromium includes instructions for how to check in new versions of
these
> headers when updating the package. Same is needed for config.h anyhow.

Ack.

Care to file a bug for check licenses?

[reveman, 2015-11-09 19:42:32]

On 2015/11/09 at 19:34:19, thestig wrote:
> On 2015/11/09 19:28:05, reveman wrote:
> > added piman as backup
> 
> You can add # comments to indicate this, if desired.
> 
> > The headers that are checked in are all automatically generated and not part
of
> > the source being pulled in via DEPS. Generating these protocol headers as
part
> > of the chromium build would require wayland-scanner to be installed on the
host
> > which is non-trivial to add as a build dependency on chromeos.
> > 
> > README.chromium includes instructions for how to check in new versions of
these
> > headers when updating the package. Same is needed for config.h anyhow.
> 
> Ack.
> 
> Care to file a bug for check licenses?

Yea, of course. Let me know on the bug if you think it makes sense to fix this
upstream. The files missing licensing headers are all
documentation/autotools/tests related and not used by chromium. We could just
avoid pulling these in through DEPS if that's possible?

https://codereview.chromium.org/1426583009/diff/120001/tools/checklicenses/ch...
File tools/checklicenses/checklicenses.py (right):

https://codereview.chromium.org/1426583009/diff/120001/tools/checklicenses/ch...
tools/checklicenses/checklicenses.py:559: # MIT license but some files contain
no licensing info. e.g. autogen.sh.
On 2015/11/09 at 17:41:28, Lei Zhang wrote:
> Can you file a bug for third_party/wayland not passing check_licenses?

Done. crbug.com/553573

[Lei Zhang, 2015-11-09 19:52:56]

On 2015/11/09 19:42:32, reveman wrote:
> Yea, of course. Let me know on the bug if you think it makes sense to fix this
> upstream. The files missing licensing headers are all
> documentation/autotools/tests related and not used by chromium. We could just
> avoid pulling these in through DEPS if that's possible?

I don't think selectively picking out via DEPS is possible.

Looking at the list, it's relatively small, and it is not unreasonable to ask
for license headers in those files. Whoever wants to can submit a patch upstream
and see if Wayland will take it.

[Lei Zhang, 2015-11-09 20:09:58]

and lgtm

[reveman, 2015-11-10 01:50:08]

reveman@chromium.org changed reviewers:
+ dpranke@chromium.org

[reveman, 2015-11-10 01:50:09]

+dpranke for build/config/linux/BUILD.gn

[reveman, 2015-11-10 01:50:26]

The CQ bit was checked by reveman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-11-10 01:52:10]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1426583009/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1426583009/160001

[Dirk Pranke, 2015-11-10 01:58:56]

On 2015/11/10 01:50:09, reveman wrote:
> +dpranke for build/config/linux/BUILD.gn

//build changes lgtm.

https://codereview.chromium.org/1426583009/diff/160001/third_party/wayland/BU...
File third_party/wayland/BUILD.gn (right):

https://codereview.chromium.org/1426583009/diff/160001/third_party/wayland/BU...
third_party/wayland/BUILD.gn:41: static_library("wayland_server") {
is there a reason this target is a static library and not a source_set?

https://codereview.chromium.org/1426583009/diff/160001/third_party/wayland/BU...
third_party/wayland/BUILD.gn:64: static_library("wayland_client") {
same question.

[commit-bot: I haz the power, 2015-11-10 02:33:41]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-10 02:33:42]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_asan_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_compile_dbg_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_clobber_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[reveman, 2015-11-10 02:43:50]

https://codereview.chromium.org/1426583009/diff/160001/third_party/wayland/BU...
File third_party/wayland/BUILD.gn (right):

https://codereview.chromium.org/1426583009/diff/160001/third_party/wayland/BU...
third_party/wayland/BUILD.gn:41: static_library("wayland_server") {
On 2015/11/10 at 01:58:55, Dirk Pranke wrote:
> is there a reason this target is a static library and not a source_set?

mainly because it mirrors upstream better. protocol/wayland-protocol.c can't be
part of both wayland_client and wayland_server target when using source_set and
still allow us to depend on both in the same binary (e.g. unit tests in follow
up patches). we could easily solve this by moving wayland-protocol.c to the
wayland_private target but it seemed like a good idea to instead follow the same
pattern as upstream.

let me know if you prefer that I change this. either way is fine with me.

[Dirk Pranke, 2015-11-10 03:02:22]

https://codereview.chromium.org/1426583009/diff/160001/third_party/wayland/BU...
File third_party/wayland/BUILD.gn (right):

https://codereview.chromium.org/1426583009/diff/160001/third_party/wayland/BU...
third_party/wayland/BUILD.gn:41: static_library("wayland_server") {
If you want to be able to include both wayland_client and wayland_server in the
same binary, then I would recommend that move move wayland-protocol to
wayland_private.

Compiling the same file twice as part of two different targets and then linking
them into the same binary seems like something you should avoid if at all
possible (and I would give this same feedback to the upstream maintainers).

[reveman, 2015-11-10 06:09:27]

https://codereview.chromium.org/1426583009/diff/160001/third_party/wayland/BU...
File third_party/wayland/BUILD.gn (right):

https://codereview.chromium.org/1426583009/diff/160001/third_party/wayland/BU...
third_party/wayland/BUILD.gn:41: static_library("wayland_server") {
On 2015/11/10 at 03:02:22, Dirk Pranke wrote:
> If you want to be able to include both wayland_client and wayland_server in
the same binary, then I would recommend that move move wayland-protocol to
wayland_private.
> 
> Compiling the same file twice as part of two different targets and then
linking them into the same binary seems like something you should avoid if at
all possible (and I would give this same feedback to the upstream maintainers).

added a wayland_protocol target to latest patch. this allows us to share
wayland_protocol.c between _server and _client targets and use source_set
instead of static_library while still keeping wayland_private the same as
upstream.

[Lei Zhang, 2015-11-12 22:34:20]

While we wait for infra to get things in order, have you tried to do a built
locally with the following settings? branding=Chrome buildtype=Official

[reveman, 2015-11-12 22:56:40]

On 2015/11/12 at 22:34:20, thestig wrote:
> While we wait for infra to get things in order, have you tried to do a built
locally with the following settings? branding=Chrome buildtype=Official

On ChromeOS, yes. Other platforms, no. Are there reasons for why that would be a
problem?

[Lei Zhang, 2015-11-12 23:00:06]

On 2015/11/12 22:56:40, reveman wrote:
> On 2015/11/12 at 22:34:20, thestig wrote:
> > While we wait for infra to get things in order, have you tried to do a built
> locally with the following settings? branding=Chrome buildtype=Official
> 
> On ChromeOS, yes. Other platforms, no. Are there reasons for why that would be
a
> problem?

- We may need to update the sysroot for Linux
- We may need to update the Linux installer's expected dependencies, though to
really test this, you need a Ubuntu Precise chroot.
- Who knows what else may go wrong.

[reveman, 2015-11-12 23:46:58]

On 2015/11/12 at 23:00:06, thestig wrote:
> On 2015/11/12 22:56:40, reveman wrote:
> > On 2015/11/12 at 22:34:20, thestig wrote:
> > > While we wait for infra to get things in order, have you tried to do a
built
> > locally with the following settings? branding=Chrome buildtype=Official
> > 
> > On ChromeOS, yes. Other platforms, no. Are there reasons for why that would
be a
> > problem?
> 
> - We may need to update the sysroot for Linux
> - We may need to update the Linux installer's expected dependencies, though to
really test this, you need a Ubuntu Precise chroot.

Run-time dependencies? I think libffi is already an implicit run-time dependency
as we link to libgobject and I think I saw it listed as a run-time dep somewhere
in our code.

> - Who knows what else may go wrong.

Right, I'll try branding=Chrome buildtype=Official locally on my linux
workstation. If you have additional tests I should run let me know.

[Lei Zhang, 2015-11-12 23:50:23]

On 2015/11/12 23:46:58, reveman wrote:
> > - We may need to update the Linux installer's expected dependencies, though
to
> really test this, you need a Ubuntu Precise chroot.
> 
> Run-time dependencies? I think libffi is already an implicit run-time
dependency
> as we link to libgobject and I think I saw it listed as a run-time dep
somewhere
> in our code.
> 
> > - Who knows what else may go wrong.
> 
> Right, I'll try branding=Chrome buildtype=Official locally on my linux
> workstation. If you have additional tests I should run let me know.

That's all I can think of right now. Basically there's no official build
coverage on the trybots, so you can do some tests now, or land and see what
happens.

[reveman, 2015-11-13 15:35:28]

The CQ bit was checked by reveman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-11-13 15:35:47]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1426583009/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1426583009/200001

[commit-bot: I haz the power, 2015-11-13 18:26:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-13 18:26:17]

Dry run: This issue passed the CQ dry run.

[reveman, 2015-11-13 23:52:31]

On 2015/11/12 at 23:50:23, thestig wrote:
> On 2015/11/12 23:46:58, reveman wrote:
> > > - We may need to update the Linux installer's expected dependencies,
though to
> > really test this, you need a Ubuntu Precise chroot.
> > 
> > Run-time dependencies? I think libffi is already an implicit run-time
dependency
> > as we link to libgobject and I think I saw it listed as a run-time dep
somewhere
> > in our code.
> > 
> > > - Who knows what else may go wrong.
> > 
> > Right, I'll try branding=Chrome buildtype=Official locally on my linux
> > workstation. If you have additional tests I should run let me know.
> 
> That's all I can think of right now. Basically there's no official build
coverage on the trybots, so you can do some tests now, or land and see what
happens.

Built Official Chrome build locally and it complained about some versions of
libraries changing (e.g. fontconfig being newer than expected) but nothing about
libffi.

I'll try to land this but keep and eye on bots in case it causes issues.

[reveman, 2015-11-13 23:52:31]

On 2015/11/12 at 23:50:23, thestig wrote:
> On 2015/11/12 23:46:58, reveman wrote:
> > > - We may need to update the Linux installer's expected dependencies,
though to
> > really test this, you need a Ubuntu Precise chroot.
> > 
> > Run-time dependencies? I think libffi is already an implicit run-time
dependency
> > as we link to libgobject and I think I saw it listed as a run-time dep
somewhere
> > in our code.
> > 
> > > - Who knows what else may go wrong.
> > 
> > Right, I'll try branding=Chrome buildtype=Official locally on my linux
> > workstation. If you have additional tests I should run let me know.
> 
> That's all I can think of right now. Basically there's no official build
coverage on the trybots, so you can do some tests now, or land and see what
happens.

Built Official Chrome build locally and it complained about some versions of
libraries changing (e.g. fontconfig being newer than expected) but nothing about
libffi.

I'll try to land this but keep and eye on bots in case it causes issues.

[reveman, 2015-11-13 23:52:35]

The CQ bit was checked by reveman@chromium.org

[reveman, 2015-11-13 23:52:36]

The patchset sent to the CQ was uploaded after l-g-t-m from piman@chromium.org,
thestig@chromium.org, dpranke@chromium.org
Link to the patchset: https://codereview.chromium.org/1426583009/#ps200001
(title: "rebase")

[commit-bot: I haz the power, 2015-11-13 23:54:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1426583009/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1426583009/200001

[commit-bot: I haz the power, 2015-11-14 00:21:41]

Committed patchset #11 (id:200001)

[commit-bot: I haz the power, 2015-11-14 00:23:04]

Patchset 11 (id:??) landed as
https://crrev.com/754ca2c474484f29b3b33c1d2f1909c6a3193260
Cr-Commit-Position: refs/heads/master@{#359701}