Fwd: [webkit-dev] Can't build Chromium Linux

[Jeremy Orlow]

---------- Forwarded message ----------
From: Adam Barth <aba...@webkit.org>
Date: Tue, Nov 9, 2010 at 11:51 AM
Subject: [webkit-dev] Can't build Chromium Linux
To: webki...@lists.webkit.org


Both my Chromium Linux boxes are getting this compile error, which
doesn't seem to be showing up on the bots:

WebKit/chromium/third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/libvpxdec.c:27:
fatal error: vpx/vpx_decoder.h: No such file or directory

This is preventing the chromium-ews from running.  Anyone know what's going on?

Adam
_______________________________________________
webkit-dev mailing list
webki...@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Denis Lagno]

We saw libvpx-related errors yesterday. libvpx was moved around, so
advice from Frank Barchard was:
Try removing the src/third_party/libvpx and perform gclient sync.

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

[Jeremy Orlow]

Why aren't things like this automated?  If someone hasn't actually edited anything in a directory, shouldn't gclient just remove it?

[Adam Barth]

I tried rm -rf WebKit/chromium/third_party. No luck.

Adam

[Anton Vayvod]

I had similar errors, rm -rf ~/chrome_root/src/c/Release/obj.target helped.

Something related to libpvx wasn't built properly incrementally.

[kenorb]

Similar problem:
> sudo python -d build/gyp_chromium -D'use_system_libxml=1' build/all.gyp
Updating projects from gyp files...
Traceback (most recent call last):
File "build/gyp_chromium", line 129, in <module>
sys.exit(gyp.main(args))
File "./tools/gyp/pylib/gyp/__init__.py", line 445, in main
options.circular_check)
File "./tools/gyp/pylib/gyp/__init__.py", line 84, in Load
depth, generator_input_info, check, circular_check)
File "./tools/gyp/pylib/gyp/input.py", line 2148, in Load
depth, check)
File "./tools/gyp/pylib/gyp/input.py", line 422, in
LoadTargetBuildFile
includes, depth, check)
File "./tools/gyp/pylib/gyp/input.py", line 422, in
LoadTargetBuildFile
includes, depth, check)
File "./tools/gyp/pylib/gyp/input.py", line 422, in
LoadTargetBuildFile
includes, depth, check)
File "./tools/gyp/pylib/gyp/input.py", line 422, in
LoadTargetBuildFile
includes, depth, check)
File "./tools/gyp/pylib/gyp/input.py", line 356, in
LoadTargetBuildFile
includes, True, check)
File "./tools/gyp/pylib/gyp/input.py", line 211, in LoadOneBuildFile
raise Exception("%s not found (cwd: %s)" % (build_file_path,
os.getcwd()))
Exception: third_party/libvpx/libvpx.gyp not found (cwd: /usr/ports/
distfiles/chromium/src) while loading dependencies of remoting/
remoting.gyp while loading dependencies of chrome/chrome.gyp while
loading dependencies of chrome/browser/sync/tools/sync_tools.gyp while
loading dependencies of build/all.gyp while trying to load build/
all.gy

I don't have obj.target to remove.
Reported issue here: http://code.google.com/p/chromium/issues/detail?id=62492

> > >> > webkit-...@lists.webkit.org
> > >> >http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> > >> > --
> > >> > Chromium Developers mailing list: chromium-...@chromium.org

> > >> > View archives, change email options, or unsubscribe:
> > >> >http://groups.google.com/a/chromium.org/group/chromium-dev
>
> > > --

> > > Chromium Developers mailing list: chromium-...@chromium.org

> > > View archives, change email options, or unsubscribe:
> > >http://groups.google.com/a/chromium.org/group/chromium-dev
>
> > --

> > Chromium Developers mailing list: chromium-...@chromium.org

[Tessa MacDuff]

When I saw the above error yesterday, I ran 'svn update' from within third_party/libvpx.  After that everything ran fine.  (Not sure why gclient sync didn't do it.)

 

Chromium Developers mailing list: chromi...@chromium.org

[Marc-Antoine Ruel]

Le 9 novembre 2010 06:06, Jeremy Orlow <jor...@chromium.org> a écrit :
> Why aren't things like this automated?

The same answer as usual, because the svn client is dumb. Really. I
tried to work around it but in that specific case it's harder.