Bug 112311 – autotools build: Automagic dependencies for libsecret, geoclue, enchant, gstreamer

• Status: RESOLVED
• Resolution: INVALID
• Component: Tools / Tests

[Tobias Mueller]

Created attachment 193038 [details]
Patch to automagically detect some dependencies

Currently, running ./configure without arguments enables many things by default, regardless whether the environment actually supports the things or not. I.e. libxslt or geoclue. So it would simple fail to configure on a machine which does not have libxslt and one would have to manually configure --disable-xslt.

With the patch attached, dependencies are automagically detected. User's choice has precedence. So if a user did ./configure --enable-xslt the configure will fail if libxslt is not present. However, if the user does calls ./configure with neither --enable-xslt nor --disable-xslt, the presence of libxslt is detected and if it exists, enabled.

[WebKit Review Bot]

Attachment 193038 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'ChangeLog', u'Source/autotools/FindDependencies.m4', u'Source/autotools/ReadCommandLineArguments.m4']" exit_code: 1
ChangeLog:1:  ChangeLog entry has no bug number  [changelog/bugnumber] [5]
Total errors found: 1 in 3 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Martin Robinson]

Personally, I'm not a huge fan of this kind of thing, because it makes it easier to accidentally compile WebKit with important features missing. I think that, if anything, we should continue on a path where there are fewer configurable bits at time goes on.

Is the problem that it's difficult to find libxslt or that running configuration over and over again is tedious? If it's the latter, we've recently added Tools/gtk/install-dependencies which works (at the moment) for Fedora and Debian-based distributions.

[Tobias Mueller]

(In reply to comment #2)
> Personally, I'm not a huge fan of this kind of thing, because it makes it easier to accidentally compile WebKit with important features missing.
Hm. You are right that it "makes it easier". But at the same time, that's the feature. It makes it easier to compile WebKit. I spent a week to get it to compile. Time is still ticking. My point would be: The fewer hassles the better. And if a feature is wanted, the big configure summary is hard to miss. And one could as well raise a warning that feature X is not found and that compilation continues without, like it's currently done with the gamepad support.
I don't think that bailing out if optional dependencies are not satisfied is good behaviour. I don't recall having seen that anywhere else.

> I think that, if anything, we should continue on a path where there are fewer configurable bits at time goes on.
> 
heh. I have a patch ready that gets rid of the configuration for XSLT ;-)

So effectively we're talking about autodetecting geolocation which would not automatically be built if the library was not there. I can add a warning for that.

> Is the problem that it's difficult to find libxslt or that running configuration over and over again is tedious?

libxslt is easy, fortunately. But it's not only libxslt. I needed to get hold of 12 packages. One after another. Oh, that's the stuff on top, after the update-webkit-libs ran. I added that, and loads of other dependencies, to the optional jhbuild moduleset.
So it's not necessarily hard, but things do add up.
I don't actually know why I'm doing this to myself, but I'm confident that it's scary enough for some other people. So again: I believe the shorter the "time to webkit" is, the better.

[Martin Robinson]

(In reply to comment #3)

> libxslt is easy, fortunately. But it's not only libxslt. I needed to get hold of 12 packages. One after another. Oh, that's the stuff on top, after the update-webkit-libs ran. I added that, and loads of other dependencies, to the optional jhbuild moduleset.
> So it's not necessarily hard, but things do add up.
> I don't actually know why I'm doing this to myself, but I'm confident that it's scary enough for some other people. So again: I believe the shorter the "time to webkit" is, the better.

This makes me sad, since I've spent a lot of time trying to make it easier to build and test WebKit. Did you run Tools/gtk/install-dependencies first? If not, is there somewhere we can put the instructions to make them more prominent? If there were dependencies missing there, do you happen to remember any of them so they can be added to Tools/gtk/install-dependencies?

[Tobias Mueller]

Created attachment 193162 [details]
new patch enabling more automagic dependencies and raises warnings

(In reply to comment #4)
> This makes me sad, since I've spent a lot of time trying to make it easier to build and test WebKit.
Having WebKit shipping a jhbuild setup that runs all by itself is a huge benefit. That's very good.
> Did you run Tools/gtk/install-dependencies first?
No. I got my Fedora machine to compile. That was almost easy. It passed the configure step and then broke at some stage during compilation, because I disabled every optional dependency, hoping to make it build faster ;-) But apparently, that's not very well tested. (I suffered from bug 112033, filed bug 111862 and bug 112368)
But it's very slow and I can't use my machine while it's compiling. So I looked around for a bigger machine that I could use. I found an OpenSuSE from two years ago. It doesn't have things like the mandatory GCC 4.7 (released 1 year ago). So not only am I not on Fedora or Debian, but also non root.

> So If not, is there somewhere we can put the instructions to make them more prominent?
Hm. To be honest, I didn't know about install-dependencies and found the bundled jhbuild much later. I came from http://webkitgtk.org/?page=contribute and read both linked sites: http://webkitgtk.org/?page=download and http://trac.webkit.org/wiki/HackingGtk. Neither mention the tools. So to improve the experience for newcomers, it might be beneficial to mention the available tools to bootstrap the build environment.

> If there were dependencies missing there, do you happen to remember any of them so they can be added to Tools/gtk/install-dependencies?
Here are the packages that I installed on top of the jhbuild environment that WebKit ships but didn't : gnutls gcc libwebp icu libxslt sqlite libcroco icon-naming-utils expat dbus pango and perf.
If you think it's worth supporting a non-root, one year old building platform such as the OpenSuSE I have, I can prepare a patch of the optional moduleset and post it here, but probably in a new bug. If you say it's not worth it, I'll keep it as a dark secret for myself ;-)


But let's come back to the automagic dependencies.
I enabled more dependencies to be auto checked, namely gstreamer and enchant and supplied warnings for both, as they were enabled by default.

[Tobias Mueller]

Created attachment 194145 [details]
Updated to current git master

[Philippe Normand]

Comment on attachment 194145 [details]
Updated to current git master

View in context: https://bugs.webkit.org/attachment.cgi?id=194145&action=review

> ChangeLog:11
> +        https://bugs.webkit.org/show_bug.cgi?id=112311

Usually the line preceding the bug link is the bug title. The change description is moved below the bug link :)

> Source/autotools/FindDependencies.m4:438
> +        [enable_video="yes"
> +        enable_web_audio="yes"

So, if GStreamer is found both video and web_audio are enabled, even if only one of them was requested in the first place?

[Tobias Mueller]

Comment on attachment 194145 [details]
Updated to current git master

View in context: https://bugs.webkit.org/attachment.cgi?id=194145&action=review

>> Source/autotools/FindDependencies.m4:438
>> +        enable_web_audio="yes"
> 
> So, if GStreamer is found both video and web_audio are enabled, even if only one of them was requested in the first place?

Yes as the dependencies are the same. That behaviour can be changed with a slightly more complicated check though.

[Tobias Mueller]

Created attachment 198920 [details]
Updated to current git master

now added libsecret to the list of detected dependencies

[Philippe Normand]

(In reply to comment #8)
> (From update of attachment 194145 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=194145&action=review
> 
> >> Source/autotools/FindDependencies.m4:438
> >> +        enable_web_audio="yes"
> > 
> > So, if GStreamer is found both video and web_audio are enabled, even if only one of them was requested in the first place?
> 
> Yes as the dependencies are the same. That behaviour can be changed with a slightly more complicated check though.

The dependencies are only a part of the problem. HTML5 media and WebAudio are two different specifications. While we want HTML5 media always on if GStreamer is found it might not always be the case for WebAudio, which is less mature and actually, still webkitPrefixed for web developers.

Anyway, I suppose that's ok... In the past haven't enabled WebAudio build by default because the backends were immature but recently we discussed to enable it by default. So we can leave this is as it is, unless Martin has some objections.

[Martin Robinson]

(In reply to comment #10)

> Anyway, I suppose that's ok... In the past haven't enabled WebAudio build by default because the backends were immature but recently we discussed to enable it by default. So we can leave this is as it is, unless Martin has some objections.

I think it's a good idea to enable Web Audio by default when the tests are running for WebKit2. I'm not a fan of  disabling features automatically though. This leads to issues where people are disabling important features (like HTML5 video) without realizing it.

[Martin Robinson]

Autotools is gone now and the CMake build does make all optional dependencies optional as far as I know.

[Csaba Osztrogonác]

Comment on attachment 198920 [details]
Updated to current git master

Cleared review? from attachment 198920 [details] so that this bug does not appear in http://webkit.org/pending-review.  If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).