[chromium-dev] Xcode builds and dependencies
Last week Mark and I talked with someone in Apple's devtools team about some of the dependency problems we've seen in our builds. We have a radar open with some repro steps, but we got a workaround for what we think we're seeing. I just rolled in a GYP change that applies this workaround(*). If you see any new cases where a you have to build twice to get everything rebuilt, please send me an email with what files you edited/changed and the raw build logs/transcripts of the extra builds so I can try to figure out what else might be going wrong and needs extra builds to fix. TVL (*) - The workaround is to move all actions/rules out of targets that compile sources. So you'll see a foo target and foo Support target, where the Support one has the actions/rules and is depended on by the target listed in the GYP file. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Xcode builds and dependencies
You mean you implemented http://code.google.com/p/gyp/issues/detail?id=42 but for xcode only? On Tue, Nov 24, 2009 at 9:51 AM, Thomas Van Lenten thoma...@chromium.orgwrote: Last week Mark and I talked with someone in Apple's devtools team about some of the dependency problems we've seen in our builds. We have a radar open with some repro steps, but we got a workaround for what we think we're seeing. I just rolled in a GYP change that applies this workaround(*). If you see any new cases where a you have to build twice to get everything rebuilt, please send me an email with what files you edited/changed and the raw build logs/transcripts of the extra builds so I can try to figure out what else might be going wrong and needs extra builds to fix. TVL (*) - The workaround is to move all actions/rules out of targets that compile sources. So you'll see a foo target and foo Support target, where the Support one has the actions/rules and is depended on by the target listed in the GYP file. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Xcode builds and dependencies
On Tue, Nov 24, 2009 at 1:01 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: You mean you implemented http://code.google.com/p/gyp/issues/detail?id=42 but for xcode only? Basically, the work is generator specific, Mark and I had talked about trying to figure out how to do this in the core (in input.py), but the catch the the treating of outputs as sources, that needs to be done in the generators, so there really a good way to deal with it. TVL On Tue, Nov 24, 2009 at 9:51 AM, Thomas Van Lenten thoma...@chromium.orgwrote: Last week Mark and I talked with someone in Apple's devtools team about some of the dependency problems we've seen in our builds. We have a radar open with some repro steps, but we got a workaround for what we think we're seeing. I just rolled in a GYP change that applies this workaround(*). If you see any new cases where a you have to build twice to get everything rebuilt, please send me an email with what files you edited/changed and the raw build logs/transcripts of the extra builds so I can try to figure out what else might be going wrong and needs extra builds to fix. TVL (*) - The workaround is to move all actions/rules out of targets that compile sources. So you'll see a foo target and foo Support target, where the Support one has the actions/rules and is depended on by the target listed in the GYP file. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] SQLite compression in history database.
Long ago when developing fts1, I experimented with using zlib compression as part of the implementation. It fell by the wayside because it really didn't provide enough performance improvement (I needed an order of magnitude, it didn't provide it), and because of licensing issues (fts1/2/3 are part of core SQLite, which does not include zlib). Chromium already has zlib, and I don't think there's any particular reason not to hack our version of fts to support it. Looking at my October history file, I get the following (numbers are in megabytes): ls -lh History\ Index\ 2009-10 # -rw-r--r--@ 1 shess eng 66M Nov 24 09:38 History Index 2009-10 .../sqlite3 History\ Index\ 2009-10 select round(sum(length(c0url)+length(c1title)+length(c2body))/1024.0/1024.0,2) from pages_content; # 34.9 select round(sum(length(compress(c0url))+length(compress(c1title))+length(compress(c2body)))/1024.0/1024.0,2) from pages_content; # 12.29 select round(sum(length(block))/1024.0/1024.0,2) from pages_segments; # 24.6 select round(sum(length(compress(block)))/1024.0/1024.0,2) from pages_segments; # 14.3 pages_segments is the fts index. Since it is consulted very frequently, I'd be slightly nervous about compressing it. pages_content is the document data, which is hit after the index (or when doing a lookup by document id), so compressing it shouldn't have much performance impact. Does this seem like a win worth pursuing? -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] SQLite compression in history database.
I'm all for it. I vaguely remember people complaining about the size of our history files, and most of my history files are over 50M. -- Elliot On Tue, Nov 24, 2009 at 10:13 AM, Scott Hess sh...@chromium.org wrote: Long ago when developing fts1, I experimented with using zlib compression as part of the implementation. It fell by the wayside because it really didn't provide enough performance improvement (I needed an order of magnitude, it didn't provide it), and because of licensing issues (fts1/2/3 are part of core SQLite, which does not include zlib). Chromium already has zlib, and I don't think there's any particular reason not to hack our version of fts to support it. Looking at my October history file, I get the following (numbers are in megabytes): ls -lh History\ Index\ 2009-10 # -rw-r--r--@ 1 shess eng 66M Nov 24 09:38 History Index 2009-10 .../sqlite3 History\ Index\ 2009-10 select round(sum(length(c0url)+length(c1title)+length(c2body))/1024.0/1024.0,2) from pages_content; # 34.9 select round(sum(length(compress(c0url))+length(compress(c1title))+length(compress(c2body)))/1024.0/1024.0,2) from pages_content; # 12.29 select round(sum(length(block))/1024.0/1024.0,2) from pages_segments; # 24.6 select round(sum(length(compress(block)))/1024.0/1024.0,2) from pages_segments; # 14.3 pages_segments is the fts index. Since it is consulted very frequently, I'd be slightly nervous about compressing it. pages_content is the document data, which is hit after the index (or when doing a lookup by document id), so compressing it shouldn't have much performance impact. Does this seem like a win worth pursuing? -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] SQLite compression in history database.
On Tue, Nov 24, 2009 at 10:21 AM, Elliot Glaysher (Chromium) e...@chromium.org wrote: I'm all for it. I vaguely remember people complaining about the size of our history files, and most of my history files are over 50M. Part of the reason for this are bugs like http://code.google.com/p/chromium/issues/detail?id=24946 . Shouldn't we fix these first? -- Elliot On Tue, Nov 24, 2009 at 10:13 AM, Scott Hess sh...@chromium.org wrote: Long ago when developing fts1, I experimented with using zlib compression as part of the implementation. It fell by the wayside because it really didn't provide enough performance improvement (I needed an order of magnitude, it didn't provide it), and because of licensing issues (fts1/2/3 are part of core SQLite, which does not include zlib). Chromium already has zlib, and I don't think there's any particular reason not to hack our version of fts to support it. Looking at my October history file, I get the following (numbers are in megabytes): ls -lh History\ Index\ 2009-10 # -rw-r--r--@ 1 shess eng 66M Nov 24 09:38 History Index 2009-10 .../sqlite3 History\ Index\ 2009-10 select round(sum(length(c0url)+length(c1title)+length(c2body))/1024.0/1024.0,2) from pages_content; # 34.9 select round(sum(length(compress(c0url))+length(compress(c1title))+length(compress(c2body)))/1024.0/1024.0,2) from pages_content; # 12.29 select round(sum(length(block))/1024.0/1024.0,2) from pages_segments; # 24.6 select round(sum(length(compress(block)))/1024.0/1024.0,2) from pages_segments; # 14.3 pages_segments is the fts index. Since it is consulted very frequently, I'd be slightly nervous about compressing it. pages_content is the document data, which is hit after the index (or when doing a lookup by document id), so compressing it shouldn't have much performance impact. Does this seem like a win worth pursuing? -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] SQLite compression in history database.
Due to bugs we've seen users with 10gb history files, which may contribute to complaints. http://code.google.com/p/chromium/issues/detail?id=24947 Even if compression ends up being pretty slow, you could imagine using it for our archived history (history more than a month old). On Tue, Nov 24, 2009 at 10:21 AM, Elliot Glaysher (Chromium) e...@chromium.org wrote: I'm all for it. I vaguely remember people complaining about the size of our history files, and most of my history files are over 50M. -- Elliot On Tue, Nov 24, 2009 at 10:13 AM, Scott Hess sh...@chromium.org wrote: Long ago when developing fts1, I experimented with using zlib compression as part of the implementation. It fell by the wayside because it really didn't provide enough performance improvement (I needed an order of magnitude, it didn't provide it), and because of licensing issues (fts1/2/3 are part of core SQLite, which does not include zlib). Chromium already has zlib, and I don't think there's any particular reason not to hack our version of fts to support it. Looking at my October history file, I get the following (numbers are in megabytes): ls -lh History\ Index\ 2009-10 # -rw-r--r--@ 1 shess eng 66M Nov 24 09:38 History Index 2009-10 .../sqlite3 History\ Index\ 2009-10 select round(sum(length(c0url)+length(c1title)+length(c2body))/1024.0/1024.0,2) from pages_content; # 34.9 select round(sum(length(compress(c0url))+length(compress(c1title))+length(compress(c2body)))/1024.0/1024.0,2) from pages_content; # 12.29 select round(sum(length(block))/1024.0/1024.0,2) from pages_segments; # 24.6 select round(sum(length(compress(block)))/1024.0/1024.0,2) from pages_segments; # 14.3 pages_segments is the fts index. Since it is consulted very frequently, I'd be slightly nervous about compressing it. pages_content is the document data, which is hit after the index (or when doing a lookup by document id), so compressing it shouldn't have much performance impact. Does this seem like a win worth pursuing? -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium Builder, revision 32965
Automatically closing tree for compile on Chromium Builder http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/19463 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder --= Automatically closing tree for compile on Chromium Builder =-- Revision: 32965 Blame list: t...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Flaky SessionHistoryTest.LocationReplace, fun with investigating it
A little background: SessionHistoryTest.LocationReplace rarely fails on the buildbot (isn't even on the flakiness dashboard), but seems to be #1 flaky test on the trybot, where it fails almost every time (or so it seems to me). It also reproduces very consistently on my Windows VM, so we have a good test case. I'm trying to fix the flaky test. What the test does is quite simple: it navigates the browser to a page with a non-empty title, which then redirects (in onload handler) to a page with an empty title. It waits for the navigation to finish, and expects an empty title. However, when it flakes out, the old non-empty title remains. I verified that the test uses TabContents and NavigationController to get the tab title. I also tried using setTimeout(... , 0) in the onload handler and waiting for two navigations instead, just as an experiment. It didn't change the flaky behavior. Using about:ipc and manual testing I observed that when the test fails, the renderer doesn't send the UpdateTitle message to tell the browser that now it should display an empty title. It doesn't look like a waiting problem with the automation. I've done it manually, and the nonempty title was still there. I'm not very familiar with the renderer code. Everything seems fine on the first glance, and I don't really know where to look for things that may go wrong. One thing that may help me with the investigation is the expected sequence of events from the moment we navigate to the redirecting page. Any other hints are also welcome. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] reset bookmark sync?
is there a way to reset bookmark sync? i had it working initially but after playing around with it for a while it stopped working... thanks -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] NameError: name 'ffmpeg_asm_lib' is not defined
Hello chromium-dev,
I've started to work on building Chromium on Solaris. I've recently
finished completing the prerequisites (NSPR and NSS), and I'm moving
forward with the Linux build descriptions. I'm using a tarball
distribution. I don't run gclient sync, but gclient runhooks --
force. The instructions say that I'm going to miss on platform-
specific dependencies, but I guess I'm going miss on them anyway.
My current problem looks as follows:
mac...@netra ~/src/opencsw/pkg/chromium/trunk $ gmake build
gmake[1]: Entering directory `/home/maciej/src/opencsw/pkg/chromium/
trunk'
[= NOW BUILDING: chromium-0.32797 MODULATION isa-sparcv8:
ISA=sparcv8 =]
[extract-modulated] complete for chromium.
[patch-modulated] complete for chromium.
(cd work/build-isa-sparcv8/home/chrome-svn/tarball/chromium \
\
PATH=$PATH:/home/maciej/src/opencsw/pkg/chromium/trunk/
work/build-isa-sparcv8/depot_tools:/opt/csw/gcc4/bin \
GYP_GENERATORS=make \
gclient runhooks --force)
running '/opt/csw/bin/python src/build/gyp_chromium' in '/
home/maciej/src/opencsw/pkg/chromium/trunk/work/build-isa-sparcv8/home/
chrome-svn/tarball/chromium'
Updating projects from gyp files...
Traceback (most recent call last):
File src/build/gyp_chromium, line 79, in module
sys.exit(gyp.main(args))
File src/tools/gyp/pylib/gyp/__init__.py, line 423, in main
params, options.check)
File src/tools/gyp/pylib/gyp/__init__.py, line 83, in Load
depth, generator_input_info, check)
File src/tools/gyp/pylib/gyp/input.py, line 2004, in Load
depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 350, in
LoadTargetBuildFile
build_file_path)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 737, in
ProcessConditionsInDict
variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 886, in
ProcessVariablesAndConditionsInDict
build_file)
File src/tools/gyp/pylib/gyp/input.py, line 901, in
ProcessVariablesAndConditionsInList
ProcessVariablesAndConditionsInDict(item, is_late, variables,
build_file)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 737, in
ProcessConditionsInDict
variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 879, in
ProcessVariablesAndConditionsInDict
build_file, key)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 718, in
ProcessConditionsInDict
if eval(ast_code, {'__builtins__': None}, variables):
File string, line 1, in module
NameError: name 'ffmpeg_asm_lib' is not defined while evaluating
condition 'ffmpeg_asm_lib==1' in src/third_party/ffmpeg/ffmpeg.gyp
while loading dependencies of src/media/media.gyp while loading
dependencies of src/chrome/chrome.gyp while loading dependencies of
src/build/all.gyp while trying to load src/build/all.gyp
failed to run command: /opt/csw/bin/python src/build/gyp_chromium
gmake[1]: *** [gclient-runhooks] Error 2
gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/chromium/
trunk'
gmake: *** [build-isa-sparcv8] Error 2
My guess is that I need to build chromium-specific ffmpeg on Solaris
as a prerequisite, by following src/third_party/ffmpeg/
README.chromium. Is that correct?
Maciej
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
[chromium-dev] How do I generate an msvs_guid for the GYP file?
In http://codereview.chromium.org/428004, I introduced a new GYP target - but don't have an msvs_guid for it. I'm guessing that I can just use a value from VS Tools Create GUID, but wanted to confirm this since I didn't see any documentation on generating the guids. Chris -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] NameError: name 'ffmpeg_asm_lib' is not defined
We currently won't build on Solaris; ffmpeg is the least of your
worries. Someone contributed patches to build on FreeBSD that might
get you closer, but the patch is enormous (~100kb, I think?) so I've
been refactoring bits of it into reviewable chunks (very slowly in my
free time).
2009/11/24 Maciej Bliziński blizin...@google.com:
Hello chromium-dev,
I've started to work on building Chromium on Solaris. I've recently
finished completing the prerequisites (NSPR and NSS), and I'm moving
forward with the Linux build descriptions. I'm using a tarball
distribution. I don't run gclient sync, but gclient runhooks --
force. The instructions say that I'm going to miss on platform-
specific dependencies, but I guess I'm going miss on them anyway.
My current problem looks as follows:
mac...@netra ~/src/opencsw/pkg/chromium/trunk $ gmake build
gmake[1]: Entering directory `/home/maciej/src/opencsw/pkg/chromium/
trunk'
[= NOW BUILDING: chromium-0.32797 MODULATION isa-sparcv8:
ISA=sparcv8 =]
[extract-modulated] complete for chromium.
[patch-modulated] complete for chromium.
(cd work/build-isa-sparcv8/home/chrome-svn/tarball/chromium \
\
PATH=$PATH:/home/maciej/src/opencsw/pkg/chromium/trunk/
work/build-isa-sparcv8/depot_tools:/opt/csw/gcc4/bin \
GYP_GENERATORS=make \
gclient runhooks --force)
running '/opt/csw/bin/python src/build/gyp_chromium' in '/
home/maciej/src/opencsw/pkg/chromium/trunk/work/build-isa-sparcv8/home/
chrome-svn/tarball/chromium'
Updating projects from gyp files...
Traceback (most recent call last):
File src/build/gyp_chromium, line 79, in module
sys.exit(gyp.main(args))
File src/tools/gyp/pylib/gyp/__init__.py, line 423, in main
params, options.check)
File src/tools/gyp/pylib/gyp/__init__.py, line 83, in Load
depth, generator_input_info, check)
File src/tools/gyp/pylib/gyp/input.py, line 2004, in Load
depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 350, in
LoadTargetBuildFile
build_file_path)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 737, in
ProcessConditionsInDict
variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 886, in
ProcessVariablesAndConditionsInDict
build_file)
File src/tools/gyp/pylib/gyp/input.py, line 901, in
ProcessVariablesAndConditionsInList
ProcessVariablesAndConditionsInDict(item, is_late, variables,
build_file)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 737, in
ProcessConditionsInDict
variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 879, in
ProcessVariablesAndConditionsInDict
build_file, key)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 718, in
ProcessConditionsInDict
if eval(ast_code, {'__builtins__': None}, variables):
File string, line 1, in module
NameError: name 'ffmpeg_asm_lib' is not defined while evaluating
condition 'ffmpeg_asm_lib==1' in src/third_party/ffmpeg/ffmpeg.gyp
while loading dependencies of src/media/media.gyp while loading
dependencies of src/chrome/chrome.gyp while loading dependencies of
src/build/all.gyp while trying to load src/build/all.gyp
failed to run command: /opt/csw/bin/python src/build/gyp_chromium
gmake[1]: *** [gclient-runhooks] Error 2
gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/chromium/
trunk'
gmake: *** [build-isa-sparcv8] Error 2
My guess is that I need to build chromium-specific ffmpeg on Solaris
as a prerequisite, by following src/third_party/ffmpeg/
README.chromium. Is that correct?
Maciej
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] How do I generate an msvs_guid for the GYP file?
AFAIK, you don't need one, it was mainly for the transition period. Brad, can we remove them all? On Tue, Nov 24, 2009 at 3:27 PM, Chris Bentzel cbent...@google.com wrote: In http://codereview.chromium.org/428004, I introduced a new GYP target - but don't have an msvs_guid for it. I'm guessing that I can just use a value from VS Tools Create GUID, but wanted to confirm this since I didn't see any documentation on generating the guids. Chris -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Vista Tests (dbg)(1), revision 32974
Automatically closing tree for ipc_tests on Vista Tests (dbg)(1) http://build.chromium.org/buildbot/waterfall/builders/Vista%20Tests%20%28dbg%29%281%29/builds/16229 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Vista%20Tests%20%28dbg%29%281%29 --= Automatically closing tree for ipc_tests on Vista Tests (dbg)(1) =-- Revision: 32974 Blame list: erik...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] NameError: name 'ffmpeg_asm_lib' is not defined
For ffmpeg, you should be able to set GYP_DEFINES=use_system_ffmpeg=1 to
disable the in-tree ffmpeg build. That should get you past that stumbling
block. HTML5 video won't work, but like Evan said, that's probably the
least of your concerns.
-Albert
On Tue, Nov 24, 2009 at 1:25 PM, Evan Martin e...@chromium.org wrote:
We currently won't build on Solaris; ffmpeg is the least of your
worries. Someone contributed patches to build on FreeBSD that might
get you closer, but the patch is enormous (~100kb, I think?) so I've
been refactoring bits of it into reviewable chunks (very slowly in my
free time).
2009/11/24 Maciej Bliziński blizin...@google.com:
Hello chromium-dev,
I've started to work on building Chromium on Solaris. I've recently
finished completing the prerequisites (NSPR and NSS), and I'm moving
forward with the Linux build descriptions. I'm using a tarball
distribution. I don't run gclient sync, but gclient runhooks --
force. The instructions say that I'm going to miss on platform-
specific dependencies, but I guess I'm going miss on them anyway.
My current problem looks as follows:
mac...@netra ~/src/opencsw/pkg/chromium/trunk $ gmake build
gmake[1]: Entering directory `/home/maciej/src/opencsw/pkg/chromium/
trunk'
[= NOW BUILDING: chromium-0.32797 MODULATION isa-sparcv8:
ISA=sparcv8 =]
[extract-modulated] complete for chromium.
[patch-modulated] complete for chromium.
(cd work/build-isa-sparcv8/home/chrome-svn/tarball/chromium \
\
PATH=$PATH:/home/maciej/src/opencsw/pkg/chromium/trunk/
work/build-isa-sparcv8/depot_tools:/opt/csw/gcc4/bin \
GYP_GENERATORS=make \
gclient runhooks --force)
running '/opt/csw/bin/python src/build/gyp_chromium' in '/
home/maciej/src/opencsw/pkg/chromium/trunk/work/build-isa-sparcv8/home/
chrome-svn/tarball/chromium'
Updating projects from gyp files...
Traceback (most recent call last):
File src/build/gyp_chromium, line 79, in module
sys.exit(gyp.main(args))
File src/tools/gyp/pylib/gyp/__init__.py, line 423, in main
params, options.check)
File src/tools/gyp/pylib/gyp/__init__.py, line 83, in Load
depth, generator_input_info, check)
File src/tools/gyp/pylib/gyp/input.py, line 2004, in Load
depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 350, in
LoadTargetBuildFile
build_file_path)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 737, in
ProcessConditionsInDict
variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 886, in
ProcessVariablesAndConditionsInDict
build_file)
File src/tools/gyp/pylib/gyp/input.py, line 901, in
ProcessVariablesAndConditionsInList
ProcessVariablesAndConditionsInDict(item, is_late, variables,
build_file)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 737, in
ProcessConditionsInDict
variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 879, in
ProcessVariablesAndConditionsInDict
build_file, key)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 718, in
ProcessConditionsInDict
if eval(ast_code, {'__builtins__': None}, variables):
File string, line 1, in module
NameError: name 'ffmpeg_asm_lib' is not defined while evaluating
condition 'ffmpeg_asm_lib==1' in src/third_party/ffmpeg/ffmpeg.gyp
while loading dependencies of src/media/media.gyp while loading
dependencies of src/chrome/chrome.gyp while loading dependencies of
src/build/all.gyp while trying to load src/build/all.gyp
failed to run command: /opt/csw/bin/python src/build/gyp_chromium
gmake[1]: *** [gclient-runhooks] Error 2
gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/chromium/
trunk'
gmake: *** [build-isa-sparcv8] Error 2
My guess is that I need to build chromium-specific ffmpeg on Solaris
as a prerequisite, by following src/third_party/ffmpeg/
README.chromium. Is that correct?
Maciej
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Re: [chromium-dev] reset bookmark sync?
Hello Rakka, The chromium-dev mailing list is meant for development related discussions and not for reporting issues such as the one you describe. Can you please open a bug through http://www.crbug.com and provide detailed info about the repro steps and the symptoms? Also, include the output from about:sync in the bug's description. We can continue the discussion in the bug (feel free to email the bug number directly to me once you open it). On Tue, Nov 24, 2009 at 8:15 AM, Rakka Rage rakkar...@gmail.com wrote: is there a way to reset bookmark sync? i had it working initially but after playing around with it for a while it stopped working... thanks -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- -Idan -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Extensions performance data
So, I eventually managed to embed some DOM benchmarks into extension. The patch I sent (with one fix) buys us roughly 20%, after it benchmarks ran as a content script lag something like 4% compared to same benchmarks ran w/o any content script. Detailed data: https://spreadsheets.google.com/a/google.com/ccc?key=toKIzdJ38bMbcS7sBt6a-vQ (sorry, Google-internal). I'd appreciate if someone would have look at extensions I wrote to estimate how representative they are (they required minor tweaks to benchmarks, changing top to parent due to another embedding): http://www.corp.google.com/~antonm/extensions/ Overall, I'd suggest to add them to perf buildbots: as of current they need some massaging to get rid of, e.g., absolute paths, but that should be doable. Two problems I can immediately see: 1) they take a notable amount of time, 2) I don't know if it's possible/easy to install an extension into the test. Any comments are most appreciated, yours, anton. On Fri, Nov 6, 2009 at 7:46 AM, Adam Barth aba...@chromium.org wrote: Try running a DOM benchmark while there is a content script that's waiting for a message from a background page. Adam On Thu, Nov 5, 2009 at 12:12 PM, Anton Muhin ant...@chromium.org wrote: Adam, all, I've got http://codereview.chromium.org/355047/ which should speed up accessing isolated worlds (it at least passes layout tests). Could someone either see if it helps or give me instructions how to bench it? yours, anton. On Tue, Oct 27, 2009 at 8:04 PM, Anton Muhin ant...@chromium.org wrote: On Tue, Oct 27, 2009 at 8:00 PM, Adam Barth aba...@chromium.org wrote: On Tue, Oct 27, 2009 at 9:52 AM, Anton Muhin ant...@chromium.org wrote: if we're sure accessing hidden property is a bottleneck, it should be easily solvable: for long time I was toying idea to compile this code into native, but didn't see compelling enough reason to do that. The easy way to measure it would be to hack stuff a bit and put data as in internal field or just add another getter to context. If you like, I can try to do something like that, but I need a simplistic benchmark to estimate performance gain. I suspect you'll see a performance gain on any simple DOM benchmark that runs in the isolated world. That code path is hit on every wrapper lookup. Ok, I will try to have a look at it this week. yours, anton. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium Linux, revision 32988
Automatically closing tree for compile on Chromium Linux http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux/builds/8013 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux --= Automatically closing tree for compile on Chromium Linux =-- Revision: 32979, 32980, 32981, 32982, 32983, 32984, 32985, 32986, 32987, 32988 Blame list: a...@chromium.org,andyb...@chromium.org,john...@chromium.org,kat...@google.com,scher...@chromium.org,timur...@chromium.org,t...@chromium.org,vand...@chromium.org,xiy...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Modules Mac, revision 33018
Automatically closing tree for net_unittests on Modules Mac http://build.chromium.org/buildbot/waterfall/builders/Modules%20Mac/builds/17352 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20Mac --= Automatically closing tree for net_unittests on Modules Mac =-- Revision: 33018 Blame list: mbel...@google.com Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] build errors while compiling tcmalloc with gcc 4.4
Greetings chromium developers,
Today, I encountered some the following build errors while compiling
tcmalloc with gcc 4.4.
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Compiling
/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc/src/symbolize.o
Compiling
/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc_linux.o
Compiling
/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc_unittests/unittest_utils.o
In file included from tcmalloc/src/symbolize.cc:37:
tcmalloc/src/symbolize.h:45: error: 'uintptr_t' was not declared in this scope
tcmalloc/src/symbolize.h:45: error: template argument 1 is invalid
tcmalloc/src/symbolize.h:45: error: template argument 3 is invalid
tcmalloc/src/symbolize.h:45: error: template argument 4 is invalid
tcmalloc/src/symbolize.h:45: error: invalid type in declaration
before ';' token
unittest_utils.cc:10: error: 'size_t' has not been declared
unittest_utils.cc: In function 'int snprintf(char*, int, const char*, ...)':
unittest_utils.cc:12: error: 'va_list' was not declared in this scope
unittest_utils.cc:12: error: expected ';' before 'args'
unittest_utils.cc:13: error: 'args' was not declared in this scope
unittest_utils.cc:13: error: 'va_start' was not declared in this scope
unittest_utils.cc:14: error: '_vsnprintf' was not declared in this scope
unittest_utils.cc:15: error: 'va_end' was not declared in this scope
scons: ***
[/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc_unittests/unittest_utils.o]
Error 1
tcmalloc/src/symbolize.cc: In function 'bool Symbolize(char*, int,
SymbolMap*)':
tcmalloc/src/symbolize.cc:134: error: expected initializer before 'iter'
tcmalloc/src/symbolize.cc:135: error: 'iter' was not declared in this scope
tcmalloc/src/symbolize.cc:135: error: request for member 'end' in '*
symbolization_table', which is of non-class type 'int'
tcmalloc/src/symbolize.cc:168: error: expected initializer before 'fill'
tcmalloc/src/symbolize.cc:172: error: 'fill' was not declared in this scope
tcmalloc/src/symbolize.cc:140: warning: ignoring return value of
'ssize_t write(int, const void*, size_t)', declared with attribute
warn_unused_result
scons: ***
[/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc/src/symbolize.o]
Error 1
tcmalloc_linux.cc: In function 'void PrintStats(int)':
tcmalloc_linux.cc:491: warning: ignoring return value of 'ssize_t
write(int, const void*, size_t)', declared with attribute
warn_unused_result
tcmalloc_linux.cc: In function 'void ReportLargeAlloc(Length, void*)':
tcmalloc_linux.cc:779: warning: ignoring return value of 'ssize_t
write(int, const void*, size_t)', declared with attribute
warn_unused_result
scons: building terminated because of errors.
It seems tcmalloc code forgot including inttypes.h before using
uintptr_t and forgot checking the return values of write(), which is a
function with a warn_unused_result attribute.
Even though the attached patch tcmalloc_gcc44.txt can fix these
build errors, I would like to ask experts here since this is a
third_party library and I cannot change it. (I don't have any good
idea to fix unittest_utils.cc since vsnprintf() needs a define
_BSD_SOURCE (or _ISOC99_SOURCE) on Linux.)
Regards,
Hironori Bono
E-mail: hb...@chromium.org
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-devIndex: tcmalloc_linux.cc
===
--- tcmalloc_linux.cc (revision 33040)
+++ tcmalloc_linux.cc (working copy)
@@ -488,7 +488,7 @@
char* buffer = new char[kBufferSize];
TCMalloc_Printer printer(buffer, kBufferSize);
DumpStats(printer, level);
- write(STDERR_FILENO, buffer, strlen(buffer));
+ ssize_t size = write(STDERR_FILENO, buffer, strlen(buffer));
delete[] buffer;
}
@@ -776,7 +776,7 @@
printer.printf( %p, stack.stack[i]);
}
printer.printf(\n);
- write(STDERR_FILENO, buffer, strlen(buffer));
+ ssize_t size = write(STDERR_FILENO, buffer, strlen(buffer));
}
namespace {
Index: tcmalloc/src/symbolize.h
===
--- tcmalloc/src/symbolize.h(revision 77)
+++ tcmalloc/src/symbolize.h(working copy)
@@ -33,6 +33,10 @@
#ifndef TCMALLOC_SYMBOLIZE_H_
#define TCMALLOC_SYMBOLIZE_H_
+#ifdef HAVE_INTTYPES_H
+#include inttypes.h
+#endif
+
#include map
using std::map;
Index: tcmalloc/src/symbolize.cc
===
--- tcmalloc/src/symbolize.cc (revision 77)
+++ tcmalloc/src/symbolize.cc (working copy)
@@ -137,7 +137,7 @@
0x% PRIxPTR \n, iter-first);
// TODO(glider): the number of write()s can be reduced by using
// snprintf() here.
-
[chromium-dev] Re: build errors while compiling tcmalloc with gcc 4.4
Greetings, Thank you so much for fixing this. :) I verified I could compile r33049 with gcc 4.4 (Ubuntu 9.10) without any errors. Best regards, Hironori Bono E-mail: hb...@chromium.org On Wed, Nov 25, 2009 at 2:00 PM, William Chan (陈智昌) willc...@google.com wrote: This is fixed now in ToT. I note that the latest version of google-perftools fixes this issue, but we're blocked on some other cross platform issue in google-perftools before we can upgrade. I'll go bug csilvers about it again so we can unfork this soon. 2009/11/24 William Chan (陈智昌) willc...@google.com: 2009/11/24 Hironori Bono (坊野 博典) hb...@chromium.org: Greetings chromium developers, Today, I encountered some the following build errors while compiling tcmalloc with gcc 4.4. scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... Compiling /home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc/src/symbolize.o Compiling /home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc_linux.o Compiling /home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc_unittests/unittest_utils.o In file included from tcmalloc/src/symbolize.cc:37: tcmalloc/src/symbolize.h:45: error: 'uintptr_t' was not declared in this scope tcmalloc/src/symbolize.h:45: error: template argument 1 is invalid tcmalloc/src/symbolize.h:45: error: template argument 3 is invalid tcmalloc/src/symbolize.h:45: error: template argument 4 is invalid tcmalloc/src/symbolize.h:45: error: invalid type in declaration before ';' token unittest_utils.cc:10: error: 'size_t' has not been declared unittest_utils.cc: In function 'int snprintf(char*, int, const char*, ...)': unittest_utils.cc:12: error: 'va_list' was not declared in this scope unittest_utils.cc:12: error: expected ';' before 'args' unittest_utils.cc:13: error: 'args' was not declared in this scope unittest_utils.cc:13: error: 'va_start' was not declared in this scope unittest_utils.cc:14: error: '_vsnprintf' was not declared in this scope unittest_utils.cc:15: error: 'va_end' was not declared in this scope scons: *** [/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc_unittests/unittest_utils.o] Error 1 tcmalloc/src/symbolize.cc: In function 'bool Symbolize(char*, int, SymbolMap*)': tcmalloc/src/symbolize.cc:134: error: expected initializer before 'iter' tcmalloc/src/symbolize.cc:135: error: 'iter' was not declared in this scope tcmalloc/src/symbolize.cc:135: error: request for member 'end' in '* symbolization_table', which is of non-class type 'int' tcmalloc/src/symbolize.cc:168: error: expected initializer before 'fill' tcmalloc/src/symbolize.cc:172: error: 'fill' was not declared in this scope tcmalloc/src/symbolize.cc:140: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result scons: *** [/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc/src/symbolize.o] Error 1 tcmalloc_linux.cc: In function 'void PrintStats(int)': tcmalloc_linux.cc:491: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result tcmalloc_linux.cc: In function 'void ReportLargeAlloc(Length, void*)': tcmalloc_linux.cc:779: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result scons: building terminated because of errors. It seems tcmalloc code forgot including inttypes.h before using uintptr_t and forgot checking the return values of write(), which is a function with a warn_unused_result attribute. Even though the attached patch tcmalloc_gcc44.txt can fix these build errors, I would like to ask experts here since this is a third_party library and I cannot change it. (I don't have any good idea to fix unittest_utils.cc since vsnprintf() needs a define _BSD_SOURCE (or _ISOC99_SOURCE) on Linux.) I don't know about the unittest_utils.cc error, I'd have to look it up, but for the rest of them, here's probably the best thing to do right now: (1) The patch to tcmalloc_linux.cc is fine since it's already forked. (2) Fork all the .cc files that reference symbolize.h, add the inttypes.h include before the symbolize.h include. This seems to be symbolize.cc and heap-profile-table.cc (we don't use debugallocation.cc yet). We can't fix symbolize.h by forking it directly because the #include's will prefer the symbolize in the current directory, rather than the one you forked. See issue 27911 for a more complete explanation. sgk's fixing this. To fork it properly, add the new files in third_party/tcmalloc/ and make your edits there. Edit tcmalloc.gyp to add those two new sources, and make sure to subtract them from the windows build and subtract the old sources from the linux build. Yes, it's a mess. It'll get fixed soon.
Re: [chromium-dev] Flaky SessionHistoryTest.LocationReplace, fun with investigating it
On Wed, Nov 25, 2009 at 00:07, Evan Stade est...@google.com wrote: sounds like http://crbug.com/22560 Thanks for finding it. /me votes for removing the Mstone-X label from it, bumping priority to Pri-2, adding a FlakyTest label and details about SessionHistoryTest.LocationReplace, and finally closing the SessionReplace bug as a duplicate of 22560. I can do that if nobody objects. To summarize the flakiness of this test: on buildbot it didn't get to the flakiness dashboard, but on the trybot it seems to fail almost every time. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
