Bug 195889 - [WPE][GTK] Building with experimental features enabled from tarball fails
Summary: [WPE][GTK] Building with experimental features enabled from tarball fails
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adrian Perez
URL:
Keywords:
Depends on: 196222 196223
Blocks:
  Show dependency tree / graph
 
Reported: 2019-03-18 09:08 PDT by Adrian Perez
Modified: 2019-03-25 15:59 PDT (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Perez 2019-03-18 09:08:59 PDT 
It seems that the “ThirdParty/openvr” subdirectory not being included
in tarballs is the culprit:

  CMake Error at Source/CMakeLists.txt:28 (add_subdirectory):
    add_subdirectory given source "ThirdParty/openvr" which is not an existing
    directory.

Originally reported at https://github.com/Igalia/meta-webkit/issues/70
Comment 1 Adrian Perez 2019-03-18 09:33:23 PDT 
Trying to build with experimental features enabled from tarballs would
also fail for the GTK port, and not only due to the “ThirdParty/openvr/”
directory being missing. In “Tools/{gtk,wpe}/manifest.txt.in” we have
the following snippet for both ports:

  directory Source
  exclude Source/JavaScriptCore/tests
  exclude Source/ThirdParty/capstone
  exclude Source/ThirdParty/libwebrtc
  exclude Source/ThirdParty/qunit
  exclude Source/ThirdParty/openvr

This means that trying to build the WebRTC support (which is also an
experimental feature) will fail as well. Should we actually add BOTH
the “ThirdParty/openvr/” and “ThirdParty/libwebrtc/” subdirectories
to tarballs?
Comment 2 Adrian Perez 2019-03-18 09:34:50 PDT 
(CC'd some of people more involved with the GTK and WPE port
releases, to get them into the discussion.)
Comment 3 Michael Catanzaro 2019-03-18 10:40:22 PDT 
(In reply to Adrian Perez from comment #1)
> This means that trying to build the WebRTC support (which is also an
> experimental feature) will fail as well. Should we actually add BOTH
> the “ThirdParty/openvr/” and 

Our experimental features flag is intended for features under active development. OpenVR does not qualify, so I would just disable it unconditionally.

> “ThirdParty/libwebrtc/” subdirectories to tarballs?

We agreed not to include it in tarballs until we have removed the dependency on BoringSSL.
Comment 4 Michael Catanzaro 2019-03-18 10:40:57 PDT 
I don't see why experimental features would be expected to work in tarballs anyway. Isn't this build flag PRIVATE so users cannot see it?
Comment 5 Adrian Perez 2019-03-25 15:59:33 PDT 
We have agreed to make a builds from tarballs be possible when
ENABLE_EXPERIMENTAL_FEATURES is enabled; in particular:

 - Figure out the minimum set of sources needed to be included in
   release tarballs for libwebrtc, see bug #196222

 - Make the WebVR support not depend on ENABLE_EXPERIMENTAL_FEATURES
   and also do not include for now the needed third party code in
   tarballs, see bug #196223

This is left as tracker bug for any build failure *from tarballs*
(as generated by “make dist” or “ninja dist”) when experimental
features are enabled.