Hi, I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can
I do? I'm using make build on 64bit Linux.
Regards
James Su
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or
On Tue, Sep 22, 2009 at 12:07 AM, James Su su...@chromium.org wrote:
I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can I
do? I'm using make build on 64bit Linux.
Yes, e.g. create ~/.gyp/include.gypi
{
'variables': {
'release_extra_cflags': '-g',
Thanks, I'll try.
James Su
2009/9/22 Dan Kegel d...@kegel.com
On Tue, Sep 22, 2009 at 12:07 AM, James Su su...@chromium.org wrote:
I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can
I
do? I'm using make build on 64bit Linux.
Yes, e.g. create ~/.gyp/include.gypi
{
Looks like both CXXFLAGS=foo make and CXXFLAGS=foo hammer ignore
CXXFLAGS. Is this by design?
On Tue, Sep 22, 2009 at 12:07 AM, James Su su...@chromium.org wrote:
Hi,
I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can I
do? I'm using make build on 64bit Linux.
Regards
I've confirmed this with Xcode 3.2; but my suspicion is it also happens with
Xcode 3.1.x, just less frequently.
In our build process, we run scripts in a few places to generate headers.
Those steps are usually done via Actions on targets. We have listed all of
the outputs generated so the tool
VS has the same kinds of problem when a project is reusing files
generated inside it. The fix is usually splitting the project in two
so that generated files by a rule/action aren't reused inside the same
project.
On Tue, Sep 22, 2009 at 8:30 AM, Thomas Van Lenten
thoma...@chromium.org wrote:
For Make, I don't see any reason off the top of my head why that shouldn't
work.
For SCons, seems like no one's ever had the itch to add CXXFLAGS (and
CCFLAGS) to the scons_import_variables list in build/common.gypi. LGTM if
you're so inclined to add it.
--SK
On Tue, Sep 22, 2009 at 1:32
I have a vague recollection of reviewing a change recently that I
think in retrospect broke this for make. The trickiness is that each
foo.o: foo.cc line has a target-local definition of CXXFLAGS,
because otherwise any file mutating CXXFLAGS would mutate it for all
rules.
Without thinking
I'd suspect an alignment / positioning bug for what you're seeing.
Often rect fill algorithms have several paths with different loop
unrolling tricks based on the size and position of the rect. I agree
with Evan that it may be worth tracking this down a bit more. Even if
it's not our bug, we
I thought it was a well written and thoughtful piece, and the
bookmarks star is not obvious for Firefox users as you have a load of
bookmark options in the right button click menu, on tabs as well. Is
this something that could be considered?
It also makes sense if you are at the bottom of a page
If you use (or consider using) Git, and also work on webkit (or any other
3rd party dependency actually) you may find the following valuable:
The latest depot_tools (revision 26817+) makes it possible to use git-try
to simultaneously test changes in both chromium and webkit. Simply type:
git try
Thank you so much for doing this!
:DG
On Tue, Sep 22, 2009 at 9:39 AM, Yaar Schnitman y...@chromium.org wrote:
If you use (or consider using) Git, and also work on webkit (or any other
3rd party dependency actually) you may find the following valuable:
The latest depot_tools (revision
On Mon, Sep 21, 2009 at 4:52 AM, Elliot Glaysher (Chromium)
e...@chromium.org wrote:
On Sun, Sep 20, 2009 at 7:43 PM, Evan Martin e...@chromium.org wrote:
- CSS occasionally lost while browsing
My response: I think I've seen this too, but I had been assuming it's
site glitches. Does this
I'm not sure I understand what you're saying. I assume you're aware
that script phases in XCode list explicit dependencies.
I think I'd have an easier time parsing your paragraph with specific examples.
-eric
On Tue, Sep 22, 2009 at 5:30 AM, Thomas Van Lenten
thoma...@chromium.org wrote:
Hello,
The Chromium team will be putting a lot of focus over the next few months on
WebKit layout tests. In fact, we've created a Layout Tests Task Force, and
anyone is welcome to contribute.
As you know, layout tests are used to check the correctness of the renderer.
Existing documentation on
Do we have anything running which monitors disk free space? It seems like in
a couple of cases over the last few months getting email alerts when a bot's
disk is 90% full might have helped alert Sheriffs/Troopers to a problem
earlier and possibly prevent a tree closure.
On Mon, Sep 21, 2009 at
Hello,
As mentioned previously, a Layout Tests Task Force has been created to
tackle the noble problem of fixing all of the WebKit layout tests that
Chromium is currently failing.
(Documentation on the task force is here:
On Mon, Sep 21, 2009 at 10:53 AM, Antony Sargent asarg...@chromium.orgwrote:
Do we have anything running which monitors disk free space? It seems like
in a couple of cases over the last few months getting email alerts when a
bot's disk is 90% full might have helped alert Sheriffs/Troopers to a
On Tue, Sep 22, 2009 at 10:39 AM, Daniel Cowx daniel.c...@gmail.com wrote:
Can someone please provide a bit of insight into how to solve the
following problem:
1. Open Chromium Options Show saved passwords
2. Click the Remove All button
Now, *before* you click Yes or No, close the main
If this is caught in the unit tests ~1/30 times, then it's happening despite
the window positionings and view positionings being the same. There's
multiple layers of indirection in there (two context types, four libraries)
all totally closed source. Tracking it down feels like it would take way
On Tue, Sep 22, 2009 at 10:26 AM, Jeffrey Chang jeffr...@google.com wrote:
- Fix all Windows layout tests: make test_expectations.txt only contain
items that we will never fix, features we have not yet implemented, or bugs
less than one week old that are a result of a recent WebKit
Yep. Dirk was the one to suggest bringing it back. I didn't put this
in the documentation, but only because I wasn't yet sure whether we'll
track them by bug milestone or explicitly using the tag.
:DG
On Tue, Sep 22, 2009 at 11:33 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, Sep 22, 2009 at
After hitting this message about twenty times over the last couple days,
and getting pinged by various people about it,
I went looking for a corresponding bug report.
The closest match seems to be
http://crbug.com/22623
so I updated that and marked it high priority.
I'm in the middle of a 2-step commit, so PLEASE DONT EDIT these files until
the commit is through.
These two gyp files have been upstreamed to webkit.org and are about to be
removed from the chromium tree.
src/webkit/webcore.gyp moved to
src/third_party/WebKit/WebCore/WebCore.gyp/WebCore.gyp
In the case you indicated, the main thread call stack probably includes the
invocation of the nested message loop. I think this nesting is usally
required because we enter a special windows message loop that handles native
windows (dialog boxes). We use some very fancy footwork to cause this
When you see this error page, it is helpful to report the error code.
Please toggle the widget to reveal the error code.-Darin
On Tue, Sep 22, 2009 at 11:39 AM, Dan Kegel d...@kegel.com wrote:
After hitting this message about twenty times over the last couple days,
and getting pinged by
It only takes a few moments to figure out this information, and ensures that
the bug lands on the right person's desk.
http://src.chromium.org/viewvc/chrome/trunk/src/ can show who wrote the
initial test
For commits before we moved to the open source repository, look at
Yes, exactly. I'm working on some additional reports and dashboards
that will allow us to track the funnel of finds/fixes better as well.
-- Dirk
On Tue, Sep 22, 2009 at 11:38 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
Yep. Dirk was the one to suggest bringing it back. I didn't put this
Seriously. In a project as big as Chrome, tests are *critical* and a
disabled test can hurt a team within just a few days. This has
happened to me a few times and it is terrifying to find out a test
that you think was proving you are working had actually been disabled.
Disabling bad tests is
Hello,
Are you on the Layout Tests Task Force and wondering what your fellow
taskforcers have been up to? Are you interested in joining the task force
and want to see what everyone else has been working on?
In the spirit of transparency, we're going to try collecting and sending out
weekly status
Are there any utilities that can be used to see which native (DOM)
objects are being referenced by JavaScript objects, and to follow
references between JS objects to understand what's keeping an object
from being GCd?
(I'm working on reducing Chrome memory usage. One thing I've
I'm working on showing JS objects retainers. But this only works for
objects that live inside V8's heap. I'm not considering links between
JS wrappers and C++ objects. I know Vitaly (cc'ed) wanted to do
something about such cycles.
On Wed, Sep 23, 2009 at 01:47, Jens Alfke s...@google.com wrote:
What's the best way to attach the debugger to a browser started by a UI
test? How about doing that only in case of a crash?
I'm looking for solution both for Windows and Linux, so if you have good
techniques, it'd be really nice. I can even document them on the wiki, but
currently I'm using LOG
On Sep 22, 2009, at 2:54 PM, Mikhail Naganov wrote:
I'm working on showing JS objects retainers. But this only works for
objects that live inside V8's heap.
That would still be useful — I'd love to be able to look at all the
'Window' objects in the heap and what ref chain is keeping them
Because we have C++ and JS wrappers, and there may be references known to
the C++ side not known to the JS side, we have to do an object grouping
before we can call GC. This grouping takes all wrappers and groups them by
their root; and then they are collected together. This happens in
On Linux and mac, if you set the BROWSER_WRAPPER environment variable,
it'll run that as a prefix of chrome. E.g., BROWSER_WRAPPER=xterm -e
gdb --args should open a new xterm with gdb for each browser window.
On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr.
phajdan...@chromium.org wrote:
If you uncomment WAIT_FOR_DEBUGGER_ON_OPEN on ui_test you'll be
prompted. We really need to convert this into a comment line option.
-Scott
On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr.
phajdan...@chromium.org wrote:
What's the best way to attach the debugger to a browser started by a UI
Both of these should go to the ui tests section of the debugging
wiki, which is where I turned in attempting to answer Pawel's
question:
http://code.google.com/p/chromium/wiki/LinuxDebugging#UI_tests
On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet s...@chromium.org wrote:
If you uncomment
WAIT_FOR_DEBUGGER_ON_OPEN predates the Linux port. It may work on
Linux, I just haven't tried it.
-Scott
On Tue, Sep 22, 2009 at 4:06 PM, Evan Martin e...@chromium.org wrote:
Both of these should go to the ui tests section of the debugging
wiki, which is where I turned in attempting to
Agreed, we should have a --browser-startup-dialog that's added to
BrowserMain. ui_tests can then pass it and --renderer-startup-dialog,
plugin-startup-dialog, in-process-plugins, --single-process along if they're
specified.
On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet s...@chromium.org wrote:
What's the difference between WAIT_FOR_DEBUGGER_ON_OPEN and
--wait-for-debugger / wait-for-debugger-children for renderers?
On Tue, Sep 22, 2009 at 4:03 PM, Scott Violet s...@chromium.org wrote:
If you uncomment WAIT_FOR_DEBUGGER_ON_OPEN on ui_test you'll be
prompted. We really need to
On windows just use windbg, and tell it to attach to child processes.
I can show you if you want.
Nicolas
On Tue, Sep 22, 2009 at 4:10 PM, Scott Violet s...@chromium.org wrote:
WAIT_FOR_DEBUGGER_ON_OPEN predates the Linux port. It may work on
Linux, I just haven't tried it.
-Scott
On
Hi,
In the last few weeks I've been trying to be aware as much as possible about
the reasons we close the tree, and
my gut feeling seems to match what I'm seeing: Webkit merges is the main
cause.
Now, I understand that Webkit merges are not easy, and really, kudos to the
team for keeping up with
On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
If this is an issue, I am proposing that Webkit merges be done outside peak
hours (11am-5pm pacific).
If we implement this, it can cause problems for cases where we need to do a
merge/land/merge pattern to coordinate
On Tue, Sep 22, 2009 at 17:40, Nicolas Sylvain nsylv...@chromium.orgwrote:
3 PM : two failing ui tests are disabled by the webkit sheriff
I was looking at the UI tests and it wasn't immediately obvious that a
webkit update might break them. Can we run all the UI tests on the webkit
canary bot?
Today wasn't a happy day for p...@. He did a seemingly innocuous roll
that broke the world: selenium, ui tests, layout tests. I am sure it
was stressful and probably added unnecessary gray to his hair.
Stuff like this happens to WebKit gardeners. We're used to breakages
upstream. That's the cost
On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain nsylv...@chromium.org wrote:
If this is an issue, I am proposing that Webkit merges be done outside peak
hours (11am-5pm pacific).
This seems backwards. Don't we want to integrate more often so we can
catch and fix these issue faster? Ideally,
There are 2 major issues here (besides leaving things for the Sheriff to
clean up):
1) a lot of the gardeners are inexperienced and drop the ball. This has
bitten us many times. The last time we had a big string of problems related
to this, I meant to send out an email giving people advice on
On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth aba...@chromium.org wrote:
On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain nsylv...@chromium.org
wrote:
If this is an issue, I am proposing that Webkit merges be done outside
peak
hours (11am-5pm pacific).
This seems backwards. Don't we want
On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth aba...@chromium.org wrote:
On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain nsylv...@chromium.org
wrote:
If this is an issue, I am proposing that Webkit merges be done outside peak
hours (11am-5pm pacific).
This seems backwards. Don't we want
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov dglaz...@google.comwrote:
Today wasn't a happy day for p...@. He did a seemingly innocuous roll
that broke the world: selenium, ui tests, layout tests. I am sure it
was stressful and probably added unnecessary gray to his hair.
Stuff like
On Tue, Sep 22, 2009 at 6:16 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
On Tue, Sep 22, 2009 at 6:10 PM, Jeremy Orlow jor...@chromium.org wrote:
There are 2 major issues here (besides leaving things for the Sheriff to
clean up):
1) a lot of the gardeners are inexperienced and drop the
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov dglaz...@google.comwrote:
Today wasn't a happy day for p...@. He did a seemingly innocuous roll
that broke the world: selenium, ui tests, layout tests. I am sure it
was stressful and probably added unnecessary gray to his hair.
Stuff like
On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote:
Is this even possible? i.e. I had uploaded a WebKit patch on codereview but
none of the patchsets got run on the try server
http://codereview.chromium.org/178030/show
It is possible:
On Tue, Sep 22, 2009 at 6:35 PM, Adam Barth aba...@chromium.org wrote:
On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org
wrote:
Is this even possible? i.e. I had uploaded a WebKit patch on codereview
but
none of the patchsets got run on the try server
I didn't say it would be easy. ;-) I also wouldn't be surprised if
window position varied across unit test runs.
I think my main point here wasn't to drop everything you're doing to
track this down. I'm just saying that it's a dangerous bug to throw
into the supression list and forget about.
Actionable items for keeping the tree green (in addition to blaming the
WebKit gardener for [insert action here]):
- *Get people putting in chromium patches upstream to run their changes
through trybots, etc*. imo, patches from @chromium folks cause well over
50% of the grief with WebKit
57 matches
Mail list logo
