[chromium-dev] Re: Cross-compiling on ARM
On Mon, Aug 24, 2009 at 6:22 PM, Antoine Labour wrote: > > On Mon, Aug 24, 2009 at 1:53 PM, Scott Hess wrote: >> Would it be possible/reasonable to use distcc plus a farm of >> cross-compiler machines to let you do faster self-hosted builds? It's >> not the "right" solution, but in the past I've found it to sometimes >> be an easier path to take in the short term while you're working on >> fixing all the little problems. >> >> -scott > > Interesting take, it might work. > Like Dean mentions, we're talking about 512 MB boards (or even 256 > MB), which in practice only means about 400 MB accessible to the OS. I > don't know how gold performs on ARM. Only x86 and x86_64 were supported at the time gold was originally released. Does it support ARM yet? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
On Tue, Aug 25, 2009 at 17:06, Lei Zhang wrote: > Only x86 and x86_64 were supported at the time gold was originally > released. Does it support ARM yet? Yes, gold can link ARM binaries as of a few months ago. I have used it in my cross compiling. Ubuntu is shipping it it in Karmic (for ARM, as well as the x86 architectures) in the binutils-gold package. Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Splitting up chrome.dll
Hello, In the past a lot of you have asked to split up chrome.dll in multiple DLLs. For this quarter, I had a goal to see how feasible this is. Background information: Breaking up chrome.dll would make linking time faster and use less memory. It would also enforce a cleaner cut between our modules. Eventually it might make some of the modules be more easily reusable or swappable. This is likely not suitable for release or official builds, because adding more dlls means slower startup time. And the penalty we would get from loading 2 or 3 more dlls won't be acceptable. This is why the scope of this change is Debug mode only. (Actually, it would be possible to enable this with a gyp define for release too, but it would be enabled by default only in debug). Oh, and this is Windows only for now too. (Linux already supports that AFAIK) The results: The good news is that it is feasible. The bad news is that the cost associated with it might be too high. This is what we need to decide here. I started by looking at base and net. Right now I have a checkout that can build the full solution with a base.dll and a net.dll. (205 modified files) The initial goal was to export only what was needed, but since the unit tests do a good job at testing almost everything, then we were exporting almost everything, so I am now exporting full classes instead. This is a lot less intrusive and the code is cleaner, even though the export table can look a little bit ugly. Some of the problems I am seeing: - ICU needs to be registered per module. Right now since the Initialize function is in base.dll, it always get initialized there, even though it's called by other dlls. We would need to move to a more central dll icu mode. I think it's already supported. - Some classes in base were clearly designed to be in a lib. One example is PathService. Right now when I call PathService::Get(FILE_MODULE), I always get "base.dll". There are some similar problems with the VersionInfo classes. The solution here would be to create a new project called base_lib, which is always a lib. Unfortunately, PathService depends on a lot of other base classes, so base.lib would need to depend on base.dll, and base.dll would need to depend on base.lib (since it does use PathService). So a major cleanup would be required here. I'm sure we can find a better solution though. - Global variables are not global for the app, they are global per module. So if you use a lib that has a global variables, and this is used from multiple dlls (base, net, chrome, etc), then they will have different values. The solution here would be to move this lib to a dll too. - Singleton. They are not too much of an issue right now because they seem to be all registered by base.dll, but there is a risk that you would have multiple instances of a singleton. (one per module). Eventually we would like to be able to split webkit in it's own dll too. I heard to it's not possible right now due to some inter-dependency problems, but people are working on that. Webkit was designed to be in its own dll, so it should be less of a problem. My next step is to back off a little bit from base and net, and go look at the other more self contained modules, like libxml and the rest of the third_party libs we use. Depending on the feedback on this thread, I will trash the base/net split, or finish it. Let me know what you think. I want to know if you have huge concerns about this, or if you think this would result in too much code change for benefit we would get out of it. Thanks Nicolas [Oh, and right now i'm using the DLL CRT, not tcmalloc. This is something else I will need to get working before we can roll this out] --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] forbidding IN_PROC_BROWSER_TESTS in unit_tests
I'm in the middle of debugging a problem which is caused by singletons. It's a very bad category of problems, because the results are initially very mysterious, until you discover that it's a singleton which carries state from one test to another. Browser tests carry a lot of state. The entire browser is started. So browser_tests launcher makes sure that the test cases are well isolated (for example it forks the process on Linux). However, I caught at least one case when IN_PROC_BROWSER_TESTS is used in unit_tests binary. It works so far, but after adding more strict checks in NotificationRegistrar (long story, I can explain if you wish) it breaks. I'm now preparing to move the file where it belongs: to browser_tests. However, it would be nice to have a flag which would enable IN_PROC_BROWSER_TEST only for browser_tests to prevent similar misuse. Like -DENABLE_IN_PROC_BROWSER_TEST or similar. What do you think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: forbidding IN_PROC_BROWSER_TESTS in unit_tests
On Tue, Aug 25, 2009 at 9:24 AM, Paweł Hajdan Jr. wrote: > I'm in the middle of debugging a problem which is caused by singletons. It's > a very bad category of problems, because the results are initially very > mysterious, until you discover that it's a singleton which carries state > from one test to another. > Browser tests carry a lot of state. The entire browser is started. So > browser_tests launcher makes sure that the test cases are well isolated (for > example it forks the process on Linux). > However, I caught at least one case when IN_PROC_BROWSER_TESTS is used in > unit_tests binary. It works so far, but after adding more strict checks in > NotificationRegistrar (long story, I can explain if you wish) it breaks. > I'm now preparing to move the file where it belongs: to browser_tests. > However, it would be nice to have a flag which would enable > IN_PROC_BROWSER_TEST only for browser_tests to prevent similar misuse. Like > -DENABLE_IN_PROC_BROWSER_TEST or similar. What do you think? Makes sense to me. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Splitting up chrome.dll
This is very cool work, it'll especially be useful for outside developers who don't have our beefy machines :) Would it be possible to get a sense of what percentage of chrome.dll is due to our code (i.e. base, net, chrome) vs third party (i.e. everything in \third_party including webkit)? Perhaps this estimate can be calculated by looking at obj file size. My hunch is that if we were to move off everything in third_party, that would get rid of a huge amount of code that hardly changes and it would be easier because that code is self contained (i.e. none of the problems that you mention below). On Tue, Aug 25, 2009 at 3:25 PM, Nicolas Sylvain wrote: > Hello, > In the past a lot of you have asked to split up chrome.dll in multiple > DLLs. For this quarter, I had a goal to see how feasible this is. > > Background information: > > Breaking up chrome.dll would make linking time faster and use less memory. > It would also enforce a cleaner cut between our modules. Eventually > it might make some of the modules be more easily reusable or swappable. > > This is likely not suitable for release or official builds, because adding > more dlls means slower startup time. And the penalty we would get from > loading 2 or 3 more dlls won't be acceptable. > > This is why the scope of this change is Debug mode only. (Actually, it > would be possible to enable this with a gyp define for release too, but it > would > be enabled by default only in debug). Oh, and this is Windows only for now > too. (Linux already supports that AFAIK) > > The results: > > The good news is that it is feasible. The bad news is that the cost > associated with it might be too high. > This is what we need to decide here. > > I started by looking at base and net. Right now I have a checkout that can > build the full solution with a base.dll and a net.dll. (205 modified files) > > The initial goal was to export only what was needed, but since the unit > tests do a good job at testing almost everything, then > we were exporting almost everything, so I am now exporting full classes > instead. This is a lot less intrusive > and the code is cleaner, even though the export table can look a little bit > ugly. > > Some of the problems I am seeing: > > - ICU needs to be registered per module. Right now since the Initialize > function is in base.dll, it always get initialized there, even though it's > called > by other dlls. We would need to move to a more central dll icu mode. I > think it's already supported. > > - Some classes in base were clearly designed to be in a lib. One example is > PathService. Right now when I call PathService::Get(FILE_MODULE), I > always get "base.dll". There are some similar problems with the VersionInfo > classes. The solution here would be to create a new project called > base_lib, which is always a lib. Unfortunately, PathService depends on a > lot of other base classes, so base.lib would need to depend on base.dll, and > base.dll would need to depend on base.lib (since it does use PathService). > So a major cleanup would be required here. I'm sure we can find a better > solution though. > > - Global variables are not global for the app, they are global per module. > So if you use a lib that has a global variables, and this is used > from multiple dlls (base, net, chrome, etc), then they will have different > values. The solution here would be to move this lib to a dll too. > > - Singleton. They are not too much of an issue right now because they seem > to be all registered by base.dll, but there is a risk that you would > have multiple instances of a singleton. (one per module). > > Eventually we would like to be able to split webkit in it's own dll too. I > heard to it's not possible right now due to some inter-dependency problems, > but people are working on that. Webkit was designed to be in its own dll, > so it should be less of a problem. > > My next step is to back off a little bit from base and net, and go look at > the other more self contained modules, like libxml and the rest of the > third_party libs we use. > > Depending on the feedback on this thread, I will trash the base/net split, > or finish it. > > Let me know what you think. I want to know if you have huge concerns about > this, or if you think this would result in too much code > change for benefit we would get out of it. > > Thanks > > Nicolas > > [Oh, and right now i'm using the DLL CRT, not tcmalloc. This is something > else I will need to get working before we can roll this out] > > > > > > > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: layout test dashboard
One more thing (since people are asking), you can see all the platforms' expectations for a test from the view for any builder. The ones that don't apply to this builder are greyed out. For example, see LayoutTests/fast/dom/HTMLObjectElement/object-as-frame.html on the "WebKit" builder. Ojan On Mon, Aug 24, 2009 at 6:42 PM, Ojan Vafai wrote: > > A first version of the layout test flakiness dashboard is up. > > http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html > > Some of the key features: > >- updates roughly as quickly as the bots have run the tests (no >post-processing, stdio parsing or crons) >- sortable by any column include "flakiness" >- builder + sort order permalinks (i.e. you can copy-paste URLs for a >given builder + sort order) >- highlights tests with missing expectations (i.e. the test passed, but >is marked only as failing) >- prints out test run times for tests that took > 1 second >- shows the expectations for a test on all platforms > > Taking a look at the dashboard, you can immediately see a couple things: > >1. A bunch of cases where we currently have the missing expectations >for a test. For example, LayoutTests/accessibility/plugin.html fails on >Windows, but is only listed as failing on the Mac. >2. We have a few dozen very slow tests that considerably slow down how >long the tests take to run. > > How do you get this awesomeness for UI tests, unittests, etc? It's actually > *really* easy. Someone just needs to add something to the test runners for > those test types that spits out JSON files in the right format and copies > them to the appropriate place. Let me know if you're interested in adding > support for a new test type. > > Known issues: > >1. The JS that generates the page could stand to be faster. >2. The windows builders have a bunch of junk entries with windows style >paths. Ignore them for now, they'll gradually fall off the end of the tests >tracked by the dashboard. Only the tests with unix style paths should be >looked at. > > If you have bugs or feature requests. Please file them at crbug.com and CC > me. One feature request that I have is to also highlight cases where we list > an expectation for a test that never happens (e.g. the test is listed as > "PASS CRASH FAIL", but has never crashed. > > Ojan > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Splitting up chrome.dll
1. So how much faster is the linking? I mean the release build
linking was the slow one. Debug linking wasn't that bad.
2. net is dependent of base.. so you could not swap base by itself,
right?
3. The native windows resource management will need to change in the
multiple dlls world. ATL has a solution so does MFC so things just
work but recall looking at them many years ago and they were fairly
complicated. Maybe they will look simple now that I've seen the guts
of a browser.
In general I think there is much that would need to change for clean
separation to work at the point that you could swap modules. Maybe you
have done this already. For example, consider an exported class Foo in
foo.h:
class Foo {
public:
Foo(Bar& );
bool DoTheThing(int x);
private:
void* window_;
};
and say it changes to:
class Foo {
public:
Foo(Bar& );
bool DoTheThing(int x);
private:
void* window_;
intstyle_;
};
DLLs built with different versions of this header will in fact
coexists (load) because none of the member functions changed, however
it we know have a bug because for the older DLLs Foo's size is 4 bytes
and for the newer DLLs Foo's size is 8 bytes. In fact when we mix them
now we have a really hard bug because the DLL that implements Foo is
accessing memory (for style_ ) that was not allocated.
For this to really work the exposed classes need to have no member
variables, which leads us to pimpl or to pure interfaces and to
factories.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Launching from Java on Mac
Hi,
I'm having some quite edge-case issues, launching chrome from Java on Mac.
Launching in Windows/Linux, calling Runtime.getRuntime().exec(new
String[] {"path/to/chrome", flag1, flag2});
works fine
Launching from Mac, doing so starts the Google Chrome process, but
does *not* give it a window/focus. I've tried throwing in a URL to
get after the flags, and still it launches no window until I click on
it in the dock.
I can get around this by then running applescript: tell application
"Google Chrome" to activate
But this only works for the case where there is one instance of Chrome
(unfortunately, I'm purposefully launching multiple instances with
different profiles).
When launching Chrome from the terminal, it opens a window properly.
When using the applescript do shell script "..." in Java, it launches
without a window.
Does anyone either:
a) Know why Chrome launches without a window, and know how to fix it?
or
b) (Less ideal) Know how to use AppleScript to traverse all running
Chrome instances to activate them all?
Thanks,
Daniel
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Splitting up chrome.dll
On Tue, Aug 25, 2009 at 8:25 AM, Nicolas Sylvain wrote: > Eventually we would like to be able to split webkit in it's own dll too. I > heard to it's not possible right now due to some inter-dependency problems, > but people are working on that. Webkit was designed to be in its own dll, > so it should be less of a problem. > Based on your other comments, I think having a WebKit DLL and an "everything else" DLL would be the best bang-for-the-buck split to work on. It's more feasible to accomplish, and it hopefully saves a much bigger chunk of compiling/linking time than splitting base/net would. I have to admit, I'm fine without split DLLs at all. I'd only do it if there's a big win. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: forbidding IN_PROC_BROWSER_TESTS in unit_tests
On Tue, Aug 25, 2009 at 9:24 AM, Paweł Hajdan Jr. wrote: > I'm in the middle of debugging a problem which is caused by singletons. > It's a very bad category of problems, because the results are initially very > mysterious, until you discover that it's a singleton which carries state > from one test to another. > Browser tests carry a lot of state. The entire browser is started. So > browser_tests launcher makes sure that the test cases are well isolated (for > example it forks the process on Linux). > > However, I caught at least one case when IN_PROC_BROWSER_TESTS is used in > unit_tests binary. It works so far, but after adding more strict checks in > NotificationRegistrar (long story, I can explain if you wish) it breaks. > > I'm now preparing to move the file where it belongs: to browser_tests. > However, it would be nice to have a flag which would enable > IN_PROC_BROWSER_TEST only for browser_tests to prevent similar misuse. Like > -DENABLE_IN_PROC_BROWSER_TEST or similar. What do you think? > > +1 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
Any chance gold will support linking Windows binaries? Linus On Tue, Aug 25, 2009 at 7:23 AM, Joel Stanley wrote: > > On Tue, Aug 25, 2009 at 17:06, Lei Zhang wrote: > > > Only x86 and x86_64 were supported at the time gold was originally > > released. Does it support ARM yet? > > Yes, gold can link ARM binaries as of a few months ago. I have used > it in my cross compiling. > > Ubuntu is shipping it it in Karmic (for ARM, as well as the x86 > architectures) in the binutils-gold package. > > Joel > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
Doubtful. It's designed for ELF binaries. On Tue, Aug 25, 2009 at 2:39 PM, Linus Upson wrote: > Any chance gold will support linking Windows binaries? > Linus > > On Tue, Aug 25, 2009 at 7:23 AM, Joel Stanley wrote: >> >> On Tue, Aug 25, 2009 at 17:06, Lei Zhang wrote: >> >> > Only x86 and x86_64 were supported at the time gold was originally >> > released. Does it support ARM yet? >> >> Yes, gold can link ARM binaries as of a few months ago. I have used >> it in my cross compiling. >> >> Ubuntu is shipping it it in Karmic (for ARM, as well as the x86 >> architectures) in the binutils-gold package. >> >> Joel >> >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Splitting up chrome.dll
On Tue, Aug 25, 2009 at 10:02 AM, John Abd-El-Malek wrote: > Would it be possible to get a sense of what percentage of chrome.dll is due > to our code (i.e. base, net, chrome) vs third party (i.e. everything in > \third_party including webkit)? Perhaps this estimate can be calculated by > looking at obj file size. WebKit was 56% of size in debug builds last I looked. (I expect a lot of weight comes from their liberal use of C++ templates.) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Splitting up chrome.dll
On Tue, Aug 25, 2009 at 8:25 AM, Nicolas Sylvain wrote: > Oh, and this is Windows only for now > too. (Linux already supports that AFAIK) Yes, but it's a bit on the unreliable side. (For some reason when I build on my laptop I have to hand-edit the resulting makefiles to get it to finally link. Others, like Craig Schlenter, have sent enough patches to keep it going it seems it must work pretty well for them.) Our instructions have bit-rotted a bit (one page referred to another which didn't have the right info). I updated http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Shared_libraries --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: forbidding IN_PROC_BROWSER_TESTS in unit_tests
uh, for which binaries are in proc browser tests allowed? I know there is one in interactive_ui_tests and it was causing problems (which caused me to go and use the code to not use statics). BrowserFocusUITests was the one. Also, and I am to blame for this one, view_id_util_unittest.cc is an in-proc browser test running on unit_tests right now. -- Evan Stade On Tue, Aug 25, 2009 at 1:28 PM, Darin Fisher wrote: > On Tue, Aug 25, 2009 at 9:24 AM, Paweł Hajdan Jr. > wrote: >> >> I'm in the middle of debugging a problem which is caused by singletons. >> It's a very bad category of problems, because the results are initially very >> mysterious, until you discover that it's a singleton which carries state >> from one test to another. >> Browser tests carry a lot of state. The entire browser is started. So >> browser_tests launcher makes sure that the test cases are well isolated (for >> example it forks the process on Linux). >> However, I caught at least one case when IN_PROC_BROWSER_TESTS is used in >> unit_tests binary. It works so far, but after adding more strict checks in >> NotificationRegistrar (long story, I can explain if you wish) it breaks. >> I'm now preparing to move the file where it belongs: to browser_tests. >> However, it would be nice to have a flag which would enable >> IN_PROC_BROWSER_TEST only for browser_tests to prevent similar misuse. Like >> -DENABLE_IN_PROC_BROWSER_TEST or similar. What do you think? > > +1 > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: forbidding IN_PROC_BROWSER_TESTS in unit_tests
On Tue, Aug 25, 2009 at 16:08, Evan Stade wrote: > uh, for which binaries are in proc browser tests allowed? I know there > is one in interactive_ui_tests and it was causing problems (which > caused me to go and use the code to not use statics). > BrowserFocusUITests was the one. For now they're allowed for all binaries, but that's bad and I'm going to change that. > Also, and I am to blame for this one, view_id_util_unittest.cc is an > in-proc browser test running on unit_tests right now. It's now being changed on the trunk. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: forbidding IN_PROC_BROWSER_TESTS in unit_tests
On Tue, Aug 25, 2009 at 4:15 PM, Paweł Hajdan Jr. wrote: > On Tue, Aug 25, 2009 at 16:08, Evan Stade wrote: >> >> uh, for which binaries are in proc browser tests allowed? I know there >> is one in interactive_ui_tests and it was causing problems (which >> caused me to go and use the code to not use statics). >> BrowserFocusUITests was the one. > > For now they're allowed for all binaries, but that's bad and I'm going to > change that. right, by allowed I mean "should be allowed" > >> >> Also, and I am to blame for this one, view_id_util_unittest.cc is an >> in-proc browser test running on unit_tests right now. > > It's now being changed on the trunk. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: forbidding IN_PROC_BROWSER_TESTS in unit_tests
I think it should only be allowed in tests that use a launcher which will properly isolate test cases. Currently interactive_ui_tests use in-proc tests. To make transition easier, I'm going to allow in-proc in them, but try to get rid of it finally (or make the launcher safer). On Tue, Aug 25, 2009 at 16:36, Evan Stade wrote: > On Tue, Aug 25, 2009 at 4:15 PM, Paweł Hajdan > Jr. wrote: > > On Tue, Aug 25, 2009 at 16:08, Evan Stade wrote: > >> > >> uh, for which binaries are in proc browser tests allowed? I know there > >> is one in interactive_ui_tests and it was causing problems (which > >> caused me to go and use the code to not use statics). > >> BrowserFocusUITests was the one. > > > > For now they're allowed for all binaries, but that's bad and I'm going to > > change that. > > right, by allowed I mean "should be allowed" > > > > >> > >> Also, and I am to blame for this one, view_id_util_unittest.cc is an > >> in-proc browser test running on unit_tests right now. > > > > It's now being changed on the trunk. > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
Note that people on Vista or Windows 7 x64 don't have slow linking issue since incremental linking is enabled, thanks to Brad. [1] So just kick anyone still complaining. M-A [1] http://src.chromium.org/viewvc/chrome?view=rev&revision=22790 On Tue, Aug 25, 2009 at 5:39 PM, Linus Upson wrote: > Any chance gold will support linking Windows binaries? > Linus > > On Tue, Aug 25, 2009 at 7:23 AM, Joel Stanley wrote: >> >> On Tue, Aug 25, 2009 at 17:06, Lei Zhang wrote: >> >> > Only x86 and x86_64 were supported at the time gold was originally >> > released. Does it support ARM yet? >> >> Yes, gold can link ARM binaries as of a few months ago. I have used >> it in my cross compiling. >> >> Ubuntu is shipping it it in Karmic (for ARM, as well as the x86 >> architectures) in the binutils-gold package. >> >> Joel >> >> > > > > > --~--~-~--~~~---~--~~ 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 to generate file under webkit.build/DerivedSources/Debug/bindings
Hi, Can you please tell me how to generate filees under webkit.build/DerivedSources/Debug/bindings? For example V8CanvasRenderingContext.cpp or /V8CanvasPixelArray.cpp? I think it is generated by this script in Webkit source: ./WebCore/bindings/scripts/generate-bindings.pl But when I cd to my ~/Webkit directory and run "./WebCore/bindings/scripts/generate-bindings.pl", I get this error: Can't locate IDLParser.pm in @INC (@INC contains: /Library/Perl/Updates/5.8.8 /System/Library/Perl/5.8.8/darwin-thread-multi-2level /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level /Library/Perl/5.8.8 /Library/Perl /Network/Library/Perl/5.8.8/darwin-thread-multi-2level /Network/Library/Perl/5.8.8 /Network/Library/Perl /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 .) at ./WebCore/bindings/scripts/generate-bindings.pl line 37. BEGIN failed--compilation aborted at ./WebCore/bindings/scripts/generate-bindings.pl line 37. I am trying to use chromium with Webkit source which I checkout using 'git svn'. Thank you for any lep --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to generate file under webkit.build/DerivedSources/Debug/bindings
I don't know the answer specifically, but this might help: If your question is how to do it by hand, src/webkit/webkit.gyp should have the answer. If you just want to compile all of chromium, you shouldn't need to worry about it: just compile Chromium however you normally would and it should generate those automatically as part of the build process. Just be sure that the version of WebKit and Chromium that you have checked out are compatible. The easiest way to be sure is to match the revision of webkit you check out to the version in the DEPS file in the root of Chromium's src. This will tell you if tip of tree for the two are currently working together: http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20Linux%20(webkit.org) On Tue, Aug 25, 2009 at 7:40 PM, hap 497 wrote: > Hi, > > Can you please tell me how to generate filees under > webkit.build/DerivedSources/Debug/bindings? > For example V8CanvasRenderingContext.cpp or /V8CanvasPixelArray.cpp? > > I think it is generated by this script in Webkit source: > ./WebCore/bindings/scripts/generate-bindings.pl > > But when I cd to my ~/Webkit directory and run > "./WebCore/bindings/scripts/generate-bindings.pl", I get this error: > Can't locate IDLParser.pm in @INC (@INC contains: > /Library/Perl/Updates/5.8.8 > /System/Library/Perl/5.8.8/darwin-thread-multi-2level > /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level > /Library/Perl/5.8.8 /Library/Perl > /Network/Library/Perl/5.8.8/darwin-thread-multi-2level > /Network/Library/Perl/5.8.8 /Network/Library/Perl > /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level > /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 .) > at ./WebCore/bindings/scripts/generate-bindings.pl line 37. > BEGIN failed--compilation aborted at > ./WebCore/bindings/scripts/generate-bindings.pl line 37. > > I am trying to use chromium with Webkit source which I checkout using 'git > svn'. > > Thank you for any lep > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux/Mac time epoch change
I just checked in r24417 which changes the "0" for times on Mac & Linux (used to mean 1970) to match Windows (1601). This means that the profiles can be copied between systems without getting the dates all wrong, and should also fix some bugs related to cookie expiration ( http://code.google.com/p/chromium/issues/detail?id=14734 ). This will be in the release notes of the next dev version affected, but I wanted to add some extra info for developers who may be affected. When you run a version of Chrome after this, it will do a one-time update of your history database to change the times, so you may notice additional lag before the new tab page or autocomplete results are available. You shouldn't have to worry about exiting in the middle of this process, it should recover. It deletes the full text index of your history, which, because of its size, didn't seem worth updating. You won't get full text search results from before the upgrade, but any browsing after that will be indexed. It also deletes any history older than 3 months rather than migrates it (this won't affect most users of Mac & Linux, since they haven't been using it that long). You can load the updated profile in previous versions of Chrome, but the dates will be far into the future, and any data added by the old version will be wrong and won't be fixed when you start using the new one again. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
