Bug 145697 - 'jhbuild build' should fail immediately when building any module fails
Summary: 'jhbuild build' should fail immediately when building any module fails
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Michael Catanzaro
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-05 09:46 PDT by Michael Catanzaro
Modified: 2015-12-07 10:54 PST (History)
8 users (show)

See Also:


Attachments
Patch (3.81 KB, patch)
2015-07-14 10:26 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff
Patch (4.85 KB, patch)
2015-07-14 11:51 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff
Patch (5.02 KB, patch)
2015-07-14 12:05 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff
Patch (4.59 KB, patch)
2015-07-14 12:56 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff
Patch (4.70 KB, patch)
2015-12-07 08:33 PST, Michael Catanzaro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2015-06-05 09:46:01 PDT
update-webkitgtk-libs currently passes --no-interact to jhbuild. It's really hard to understate how frustrating this it -- it makes jhbuild continue to build even after something has failed, and it's very difficult to discover why things fail to build, since the error is always long past normal terminal scrollback limits. Instead, I expect to immediately get a build error with the nice menu that allows me to decide how to fix the problem.

If the bots need the --no-interact behavior, we'll need to add a flag to update-webkitgtk-libs for that.
Comment 1 Carlos Alberto Lopez Perez 2015-07-09 06:44:48 PDT
(In reply to comment #0)
> update-webkitgtk-libs currently passes --no-interact to jhbuild. It's really
> hard to understate how frustrating this it -- it makes jhbuild continue to
> build even after something has failed, and it's very difficult to discover
> why things fail to build, since the error is always long past normal
> terminal scrollback limits. Instead, I expect to immediately get a build
> error with the nice menu that allows me to decide how to fix the problem.
> 
> If the bots need the --no-interact behavior, we'll need to add a flag to
> update-webkitgtk-libs for that.

JHBuild should not ask any question, so no-interact make a lot of sense.

What don't makes sense is that it continues building even when no-interact is enabled.

I have tested this patch and it fixes the problem:

--- a/jhbuild/frontends/terminal.py
+++ b/jhbuild/frontends/terminal.py
@@ -304,7 +304,7 @@ class TerminalBuildScript(buildscript.BuildScript):
         self.triedcheckout = None
 
         if not self.config.interact:
-            return 'fail'
+            sys.exit(1)
         while True:
             print
             uprint('  [1] %s' % _('Rerun phase %s') % phase)




I see two options:

a) We fork jhbuild (on github for example) and we apply this patch and then we use it as source on the script Tools/jhbuild/jhbuild-wrapper instead of using upstream git://git.gnome.org/jhbuild'

b) We add an extra step on Tools/gtk/jhbuild.modules after cloning the repo to apply a serie of patches.


Which option is preferred? If is the b. I already have it more or less ready, I can upload a patch for review.
Comment 2 Martin Robinson 2015-07-09 07:44:40 PDT
Option B sounds fine to me.
Comment 3 Carlos Alberto Lopez Perez 2015-07-13 13:56:43 PDT
Michael: thanks for reporting this upstream.

I have one doubt... if upstream merges the patch, instead of applying a patch as I suggested previously. I think we can directly raise the version of jhbuild to the one merging that patch, can't we?

Anybody seems any problem raising the version of jhbuild?

The version we are using now seems to be 3.10+, was updated for last time on bug 124966.
Comment 4 Martin Robinson 2015-07-13 13:57:35 PDT
(In reply to comment #3)

> Anybody seems any problem raising the version of jhbuild?

I don't see any issues with updating it.
Comment 5 Michael Catanzaro 2015-07-13 15:14:00 PDT
I don't either
Comment 6 Michael Catanzaro 2015-07-14 09:17:07 PDT
OK, upstream jhbuild now has an --exit-on-error option. It can be used like this:

jhbuild --exit-on-error build whatever

Or you can add to jhbuildrc:

exit_on_error = True
Comment 7 Michael Catanzaro 2015-07-14 10:26:04 PDT
Created attachment 256776 [details]
Patch
Comment 8 Carlos Alberto Lopez Perez 2015-07-14 11:23:48 PDT
The EFL EWS failed with:

Traceback (most recent call last):
  File "/home/gyuyoung/eflews/WebKit/WebKitBuild/DependenciesEFL/Source/jhbuild/jhbuild/config.py", line 197, in load
    execfile(filename, config)
  File "/home/gyuyoung/eflews/WebKit/Tools/jhbuild/../../Tools/efl/jhbuildrc", line 35, in <module>
    _libeail_path = os.path.join(os.environ['CMAKE_LIBRARY_PATH'], 'libeail.so')
  File "/usr/lib/python2.7/UserDict.py", line 23, in __getitem__
    raise KeyError(key)
KeyError: 'CMAKE_LIBRARY_PATH'


Seems this key is used also by Tools/efl/jhbuildrc
Comment 9 Michael Catanzaro 2015-07-14 11:51:59 PDT
Created attachment 256782 [details]
Patch
Comment 10 Michael Catanzaro 2015-07-14 11:55:15 PDT
I added a speculative fix for EFL; let's see if it works.

Note that after this patch, you will almost surely need to rm -rf WebKitBuild before the next time you run update-webkitgtk-libs. As long as you don't try to use jhbuild, I expect your current build directory should continue to work fine.
Comment 11 Michael Catanzaro 2015-07-14 12:05:14 PDT
Created attachment 256783 [details]
Patch
Comment 12 Michael Catanzaro 2015-07-14 12:56:11 PDT
Created attachment 256786 [details]
Patch
Comment 13 Michael Catanzaro 2015-07-14 13:22:27 PDT
GTK+ EWS just needs a clean build.

Not sure about Mac; it's massively broken, but surely they don't use jhbuild?
Comment 14 Michael Catanzaro 2015-07-14 13:37:11 PDT
OK, Mac is broken without this patch, so I think this patch is good.
Comment 15 Michael Catanzaro 2015-07-14 16:50:20 PDT
Well it should not be a problem for the bots, but my local build failed:

[5445/5718] Generating ../docs-build-no-html.stamp
FAILED: cd /home/mcatanzaro/WebKit/WebKitBuild/Release && CC=/usr/lib64/ccache/cc CFLAGS= /home/mcatanzaro/WebKit/Tools/gtk/generate-gtkdoc --skip-html && touch docs-build-no-html.stamp
Copying template files to output directory...
Running gtkdoc-scan
Running gtkdoc-scangobj
/usr/lib64/libpangoft2-1.0.so.0: undefined reference to `FcWeightToOpenType'
/usr/lib64/libpangoft2-1.0.so.0: undefined reference to `FcWeightFromOpenType'
collect2: error: ld returned 1 exit status
Linking of scanner failed:

Question is, why is it using the system pango? libpangoft2-1.0.so.0 exists in my jhbuild prefix....
Comment 16 Michael Catanzaro 2015-07-14 19:09:02 PDT
Also, it looks like libffi is broken, improperly installing itself to DependenciesGTK/Root/lib64. It must ignore the libdir set by jhbuild. That's pretty weird, since it uses autotools. Strange that doesn't seem to hurt anything.

A python2.7 folder also gets improperly created for me under DependenciesGTK/Root/lib64, but I'm pretty sure that is a Fedora bug.
Comment 17 Carlos Garcia Campos 2015-12-07 08:28:10 PST
Comment on attachment 256786 [details]
Patch

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

> Tools/gtk/jhbuildrc:36
> +os.environ['LLVMPIPE_LIBGL_PATH'] = os.path.abspath(os.path.join(checkoutroot, 'Mesa', 'lib', 'gallium'))

Note that this has changed, we use buildroot now instead of checkoutroot
Comment 18 Michael Catanzaro 2015-12-07 08:33:34 PST
Created attachment 266775 [details]
Patch
Comment 19 WebKit Commit Bot 2015-12-07 10:54:52 PST
Comment on attachment 266775 [details]
Patch

Clearing flags on attachment: 266775

Committed r193639: <http://trac.webkit.org/changeset/193639>
Comment 20 WebKit Commit Bot 2015-12-07 10:54:55 PST
All reviewed patches have been landed.  Closing bug.