[chromium-dev] Re: Question about V8 bindings
Ah, yes of course. The generated code for the base class itself needs
it. I had also forgotten that we use the ID to get the superclass
template to inherit from.
Don't listen to me. :-)
-- Mads
On Wed, Jul 22, 2009 at 10:15 PM, Drew Wilsonatwil...@chromium.org wrote:
Digging further through the errors, it seems that the generated code for the
base class itself is littered with references to the V8ClassIndex::type
value. For example:
static v8::Handlev8::Value locationAttrGetter(v8::Localv8::String
name, const v8::AccessorInfo info) {
INC_STATS(DOM.WorkerContext.location._get);
v8::Handlev8::Object holder = info.Holder();
WorkerContext* imp =
V8DOMWrapper::convertToNativeObjectWorkerContext(V8ClassIndex::WORKERCONTEXT,
holder);
I'd note that V8DOMWrapper::convertToNativeObject() is basically just a
wrapper around convertDOMWrapperToNative() which itself just pulls a pointer
value out of kDOMWrapperObjectIndex (the passed-in type is essentially
ignored except for some runtime debugging) so we could probably just
generate calls to convertDOMWrapperToNative() instead.
-atw
On Wed, Jul 22, 2009 at 12:59 PM, Drew Wilson atwil...@chromium.org wrote:
I think this may not be true, as I got a compilation error in the
generated bindings when I removed the type enum for the base class.
Note that the code generated for my derived class contains an explicit
reference to the base class:
static v8::Persistentv8::FunctionTemplate
ConfigureV8DedicatedWorkerContextTemplate(v8::Persistentv8::FunctionTemplate
desc) {
...initialization of attributes...
desc-Inherit(V8DOMWrapper::getTemplate(V8ClassIndex::WORKERCONTEXT));
desc-SetClassName(v8::String::New(DedicatedWorkerContext));
return desc;
}
So it appears that we *do* need to define the base type in this case, and
in general we need to be able to generate a template for every item in the
class hierarchy, even if that class should not be directly instantiable.
Is this correct, or am I missing something?
-atw
On Tue, Jul 21, 2009 at 10:42 PM, Mads Sig Ager a...@chromium.org wrote:
If you don't need the base 'type' in the binding layer code, you don't
have to specify it in the V8Index file. Prototype chains and
instanceof operations are all handled by V8 based on the code
generated from the IDL files and it is independent of the 'type'
declarations in the V8Index file.
Cheers, -- Mads
On Tue, Jul 21, 2009 at 6:13 PM, Drew Wilsonatwil...@chromium.org
wrote:
The other unanswered question is whether it's useful to define the base
type in V8Index.h.
If a wrapper of the base type (WRAPPERCONTEXT) is never instantiated,
do I
still need to define it for the purposes of things like instanceof
and
prototype chains? Or is it *only* used to specify the type of wrapper
instances?
-atw
On Tue, Jul 21, 2009 at 10:58 AM, Adam Barth aba...@chromium.org
wrote:
I think the way this works in general is that you create the wrapper
for the derived class. You can see all the switch statements in
V8DOMWrapper.cpp that try to do this for Nodes, etc.
Adam
On Tue, Jul 21, 2009 at 10:32 AM, Jeremy Orlowjor...@chromium.org
wrote:
On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson atwil...@google.com
wrote:
It seems like that would have some undesirable side-effects, aside
from
the fact that WebKit frowns on using virtual functions
unnecessarily.
So, let's imagine that I have two derived classes,
SharedWorkerContext
and
DedicatedWorkerContext. DedicatedWorkerContext wants to expose
postMessage()
as a public callable function, but SharedWorkerContext would not.
If we only have a single V8 class for both of these
(WORKERCONTEXT)
then
that implies:
1) I have to define postMessage() as a virtual function on the base
WebCore class (WorkerContext). In fact, WorkerContext ends up
containing the
union of all exposed APIs for every future derived class, which
seems
ugly.
2) From javascript, if I have a SharedWorkerContext, and I do this
typeof
postMessage, it should return undefined (since
SharedWorkerContext
does
not define this attribute) - however, since SharedWorkerContext is
actually
just a vanilla WORKERCONTEXT behind the scenes, it would return
function,
which violates the spec.
It seems like the right way to do this is to actually have separate
V8
items. The alternative is to have just a single WORKERCONTEXT, but
instead
of using polymorphism have custom getters/setters for every
attribute
that
check the type of the impl class and do the appropriate thing. But
it
seems
like the whole point of having the V8ClassIndex enum is to avoid
this
kind
of manual polymorphism.
Good points.
Are there other use cases for building polymorphism into V8? Is
there
any
notion of polymorphism in the IDL files? Maybe the best answer is
to
[chromium-dev] Re: FYI: Upcoming O3D integration changes.
Any idea on how much this increase the size of chrome.dll? On Wed, Jul 22, 2009 at 9:51 PM, Nicolas Sylvainnsylv...@chromium.org wrote: On Wed, Jul 22, 2009 at 11:47 AM, Greg Spencer gspen...@google.com wrote: On Wed, Jul 22, 2009 at 11:27 AM, Nicolas Sylvain nsylv...@chromium.org wrote: src/third_party/nixysa/files: why in a subdir called files? A leftover from converting from p4/scons -- I'll remove it. # NACL has to be in this weird directory because it looks for # googleclient two levels above it. src/third_party/native_client/googleclient/native_client: Looks like they should change their code to make it work without assuming all these directories. and this code is already fetched in src/native_client, we don't want it twice. Yes, that just happened recently -- I'll try to switch to using their new GYP build. For those who are curious : $ du -h --max-depth=1 . 4.1M ./gflags 34M ./native_client 1.3M ./nixysa 251K ./npapi 2.1M ./ply-3.1 24M ./vectormath 64M . And the additional native_client will disappear, so more like 30M. (and these numbers include all the .svn dirs, so the real code is half that). The docs in the vectormath library are 17M, so we could probably delete those from the repo if size is an issue, and make it 13M total. That would be great! Thanks Nicolas -Greg. --~--~-~--~~~---~--~~ 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: avoiding compile failures on buildbot
Just to be complete, linux can have the same issue, and I'd expect Windows also to be able too. This is one class of things the try server doesn't catch because it is building debug/unoptimized. TVL On Wed, Jul 22, 2009 at 10:09 PM, Andrew Scherkus scher...@chromium.orgwrote: On Wed, Jul 22, 2009 at 7:07 PM, Dan Kegel d...@kegel.com wrote: That's consistent with trybots doing debug builds. Uninitialized var warnings only show up in optimized builds, nothing we can do there but turn on optimizations. Gotcha -- thanks for the explanation! Andrew On Thu, Jul 23, 2009 at 2:00 AM, Andrew Scherkusscher...@chromium.org wrote: On a related note, Frank (cc'd) ran into an issue where the mac try bots have a less-strict compiler warning error than the build bots, which led to a broken build once he checked in: http://codereview.chromium.org/155834 Probably a simple config tweak somewhere, but interesting nonetheless. Andrew On Wed, Jul 22, 2009 at 6:19 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Jul 22, 2009 at 5:59 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: One thing that would help us keep the tree more green is avoiding compile failures. A compile failure is very bad, because without binaries the tests can't run, and then we have to wait for all of them to run, which may reveal additional failures etc. I'm actually surprised by some failures on buildbot, but at least one thing was not surprising for me: Windows Release compile failures when the Debug compiles fine (because we don't have Release trybot). How often does something run in Windows when compiled with the release configuration but not the debug? I've definitely seen it, but I'm not sure it's terribly common. My guess is that there are other causes of the build breaking that should be addressed first. Are there any stats on this? My gut feeling is that many of the build breaks are for things that never passed on a try bot. For example, WebKit gardening patches almost never work on the try bots so we just ignore them. I think working on stuff like this will bear more fruit. Not to mention that each bot costs a lot in terms of the machine, power, maintenance time, etc. What do you think? Do you have any ideas how we could avoid more compile failures, even if they are not possible to apply now due to lack of resources? (for example adding trybots, which seems to not happen soon). I was also thinking about allowing simple check-ins when the tree is waiting for cycle state (when the sheriff wants to verify that bots cycle green after a lot of redness). The status would say (Tree closed, waiting for cycle; ask sheriff to commit a simple change), or maybe some abbreviation for that. It would help people getting code in, and the sheriff could require really a lot from that change (like full green trybot pass etc). What do you think about that (especially sheriffs)? I think you can always ask the sheriffs if you can put something small in. I don't see the point of making any such message policy or a convention. That said, unless it doesn't compile or is REALLY obviously OK, I don't think it's a good idea. --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 4:56 AM, Mark Mentovaim...@chromium.org wrote: An objdir-ish solution would make sense, except the native build systems we use don't really work in terms of objdirs, so we'd just wind up generating a parallel directory structure with nothing but xcode projects, Makefiles, and other similar junk. That's right. (This is how autoconf projects work when you do an out of tree build.) Plus, it means that we can't supply a pre-gypped srcdir tarball, which can frustrate the snot out of casual developers. Sure you can; just include the build directory in the tarball. But gyp does the equivalent of 'configure', so its output depends on the system you're running it on, and it might not always be a good idea to use pre-gyp'd tarballs. I think this already bit somebody. I'm not arguing for out-of-tree builds anymore, since y'all feel so strongly about it, but if we ever decide to support cross-compiling, $objdir might start making more sense. Also, we'd have to do something like http://www.python.org/dev/peps/pep-0304/ or do 'make clean' to keep those pesky .pyc files from causing the same problems, anyway. - Dan --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Wed, Jul 22, 2009 at 9:56 PM, Mark Mentovai m...@chromium.org wrote: Dan Kegel wrote: No. Generating files is the point of gyp. Nothing says they have to be in the source tree. Out of all of the proposals out there, the only ones that make any sense to my software-developin' mind are the ones that keep the build files in the source tree. I find it much easier to type make or xcodebuild or whatever without having to keep track of where I am. Dumping all of our build files into a single directory without any real association to the source they build sucks. An objdir-ish solution would make sense, except the native build systems we use don't really work in terms of objdirs, so we'd just wind up generating a parallel directory structure with nothing but xcode projects, Makefiles, and other similar junk. Plus, it means that we can't supply a pre-gypped srcdir tarball, which can frustrate the snot out of casual developers. Maybe this could be an optional mode? Perhaps we could use this mode on the build slaves? Or... maybe for the benefit of the build slaves, GYP could write out a log of all generated files, and then as a first step, the build slaves could delete all generated files? My point is that maybe we can solve a large part of the pain here with something that addresses the needs of the build slaves only. -Darin The only change that makes any amount of sense to me would be to move all GYP-generated files one directory below where they are now, by introducing new build-file directories. That'd ease the svn:ignore burden. But those files are still in the source tree. One of the intentional properties of our current GYP setup is that the generated files are as good as checked-in. GYP generation looks and feels just like another file in the working copy being updated. I think that this transparency is a really good thing. You've pointed out a legitimate flaw, so perhaps we should focus on other solutions to that problem. There are ways to fix this that don't involve moving files around. Mark --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 7:26 AM, Darin Fisher da...@chromium.org wrote: On Wed, Jul 22, 2009 at 9:56 PM, Mark Mentovai m...@chromium.org wrote: Dan Kegel wrote: No. Generating files is the point of gyp. Nothing says they have to be in the source tree. Out of all of the proposals out there, the only ones that make any sense to my software-developin' mind are the ones that keep the build files in the source tree. I find it much easier to type make or xcodebuild or whatever without having to keep track of where I am. Dumping all of our build files into a single directory without any real association to the source they build sucks. An objdir-ish solution would make sense, except the native build systems we use don't really work in terms of objdirs, so we'd just wind up generating a parallel directory structure with nothing but xcode projects, Makefiles, and other similar junk. Plus, it means that we can't supply a pre-gypped srcdir tarball, which can frustrate the snot out of casual developers. Maybe this could be an optional mode? Perhaps we could use this mode on the build slaves? I forgot to mention that I would personally much prefer this mode than having generated files in my checked out source tree. I guess I'm very accustomed to an objdir solution from my Mozilla days (autoconf). Perhaps this objdir could even be married to the current output dirs used by the builds (xcodebuild, sconsbuild, chrome/Debug, etc.). -Darin Or... maybe for the benefit of the build slaves, GYP could write out a log of all generated files, and then as a first step, the build slaves could delete all generated files? My point is that maybe we can solve a large part of the pain here with something that addresses the needs of the build slaves only. -Darin The only change that makes any amount of sense to me would be to move all GYP-generated files one directory below where they are now, by introducing new build-file directories. That'd ease the svn:ignore burden. But those files are still in the source tree. One of the intentional properties of our current GYP setup is that the generated files are as good as checked-in. GYP generation looks and feels just like another file in the working copy being updated. I think that this transparency is a really good thing. You've pointed out a legitimate flaw, so perhaps we should focus on other solutions to that problem. There are ways to fix this that don't involve moving files around. Mark --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Wed, Jul 22, 2009 at 9:15 PM, Mark Larson (Google) m...@chromium.orgwrote: On Wed, Jul 22, 2009 at 20:27, Dan Kegel d...@kegel.com wrote: Stop me if you've heard this one before. Today, a new directory was added to the source tree, and shortly thereafter was reverted. Should have been no problem, but... because the new directory contained a gyp file, a file was generated in that directory, and svn couldn't delete the directory when the revert landed. This caused a build breakage, and I gather from nsylvain's comments that this wasn't the first time this has happened. At some point soon, it'd be good to teach gyp not to generate files in the source tree. Or maybe teach gclient how to deal forcefully with directories with no files under version control. Generating files in the source tree is kinda the point of gyp. gclient has nothing to do with this case. svn update src/ was trying to add a directory called src/bleh, but src/bleh already existed, so svn update failed. The only thing gclient might want to do, is clobber your tree, and try again. We used to have stuff like that, but they are all disabled AFAIK, I lost too many important files because gclient wanted to be nice and clean up my machine. What we currently do, on the buildbot side, is clobber the source tree when something goes wrong with gclient. In this case it mostly worked, except on about 8 machines, where a file was locked. (No idea what it was, procexp was not helpful, closing all apps either. I had to reboot the machine) To answer dirk : Well, it needs manual cleanup. Ask a trooper to connect to each machine and fix them. (Or ask on irc, at this point about half of the team knows the passwords to the machines :| ). I guess we should formalize it more : When in doubt, find someone to reboot the machine. It does not need any special skills, the machine will auto login and restart all the buildbot stuff automatically. Nicolas --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 2:28 PM, Darin Fisherda...@chromium.org wrote: An objdir-ish solution would make sense, except the native build systems we use don't really work in terms of objdirs, so we'd just wind up generating a parallel directory structure with nothing but xcode projects, Makefiles, and other similar junk. Plus, it means that we can't supply a pre-gypped srcdir tarball, which can frustrate the snot out of casual developers. Maybe this could be an optional mode? Perhaps we could use this mode on the build slaves? I forgot to mention that I would personally much prefer this mode than having generated files in my checked out source tree. I guess I'm very accustomed to an objdir solution from my Mozilla days (autoconf). Perhaps this objdir could even be married to the current output dirs used by the builds (xcodebuild, sconsbuild, chrome/Debug, etc.). Indeed. Here's my christmas wish: I'd like gyp and chrome to support cross-compilation, so that I could (on my Linux box) kick off distcc-accelerated builds for all three platforms, each one going into a separate objdir. It's not as farfetched as it sounds; Mac can already be built on Linux, I hear, and a Windows build on Linux is within reach (just have to remove the last bits of ATL and apply some elbow grease, I think). That desire is part of what makes me want gyp output to go into objdir -- because gyp's output is going to depend on which platform you're building for. - Dan --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 8:53 AM, Evan Martin e...@chromium.org wrote: On Thu, Jul 23, 2009 at 7:47 AM, Nicolas Sylvainnsylv...@chromium.org wrote: gclient has nothing to do with this case. svn update src/ was trying to add a directory called src/bleh, but src/bleh already existed, so svn update failed. Sorry to back-seat drive, but can't you do something like svn status | xargs rm -rf before syncing? svn status does not show files that are svn:ignore'd, like all generated files should be. But, that's a good point, the directory might not be ignored, so that can work. We already have code to do that and we do it on the try bots. This is really slow though, can take 1-2 minutes to run before each sync. (In git it's a builtin: git clean -f to delete all files that aren't officially part of the repository.) The only thing gclient might want to do, is clobber your tree, and try again. We used to have stuff like that, but they are all disabled AFAIK, I lost too many important files because gclient wanted to be nice and clean up my machine. I don't understand this paragraph, which might explain why my above proposal is dumb. An example that bit me in the past: You have a DEPS file that fetches src/blah. you add new code in src/blah, but before you commit, someone deletes the line src/blah in the DEPS file. At the time the default behavior was : rm -rf src/blah, which killed all my new code in there. Maybe the non-versionned files are important. We can't kill them. (We could have a mode for buildbot only that is more aggressive though, since we are not likely to have important non-versionned files there). Nicolas --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 12:00 PM, Dan Kegel d...@kegel.com wrote: On Thu, Jul 23, 2009 at 2:28 PM, Darin Fisherda...@chromium.org wrote: An objdir-ish solution would make sense, except the native build systems we use don't really work in terms of objdirs, so we'd just wind up generating a parallel directory structure with nothing but xcode projects, Makefiles, and other similar junk. Plus, it means that we can't supply a pre-gypped srcdir tarball, which can frustrate the snot out of casual developers. Maybe this could be an optional mode? Perhaps we could use this mode on the build slaves? I forgot to mention that I would personally much prefer this mode than having generated files in my checked out source tree. I guess I'm very accustomed to an objdir solution from my Mozilla days (autoconf). Perhaps this objdir could even be married to the current output dirs used by the builds (xcodebuild, sconsbuild, chrome/Debug, etc.). Indeed. Here's my christmas wish: I'd like gyp and chrome to support cross-compilation, so that I could (on my Linux box) kick off distcc-accelerated builds for all three platforms, each one going into a separate objdir. It's not as farfetched as it sounds; Mac can already be built on Linux, I hear, and a Windows build on Linux is within reach (just have to remove the last bits of ATL and apply some elbow grease, I think). A mac build still needs a Mac to drive it. We simply did the work to distribute the compiling to linux also. But the build is driven by xcode, and you need a bunch of other mac tools for the scripts to be able to invoke. Window is probably in a similar boat, you'd need the tools for compiling resources, etc. That desire is part of what makes me want gyp output to go into objdir -- because gyp's output is going to depend on which platform you're building for. At the moment, each platform is generating a native for a different build system. So the xcode project can live on disk next to the windows solution, and the makefile/scons files too. As far as object dirs go, i believe all three now already write the output into a different directory (supporting both debug and release in there). So the configure world need of different output dirs isn't the exact same situation. TVL - Dan --~--~-~--~~~---~--~~ 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: FYI: Upcoming O3D integration changes.
On Thu, Jul 23, 2009 at 2:46 AM, Dean McNamee de...@chromium.org wrote: Any idea on how much this increase the size of chrome.dll? Not yet - I'll let you know as soon as we're ready (some symbols are still not being referenced, so the count probably isn't accurate yet). -Greg. --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 9:07 AM, Thomas Van Lententhoma...@chromium.org wrote: Here's my christmas wish: I'd like gyp and chrome to support cross-compilation, so that I could (on my Linux box) kick off distcc-accelerated builds for all three platforms, each one going into a separate objdir. It's not as farfetched as it sounds; Mac can already be built on Linux, I hear, and a Windows build on Linux is within reach (just have to remove the last bits of ATL and apply some elbow grease, I think). A mac build still needs a Mac to drive it. We simply did the work to distribute the compiling to linux also. But the build is driven by xcode, and you need a bunch of other mac tools for the scripts to be able to invoke. OK then, let's make a Mac drive all three builds :-) Window is probably in a similar boat, you'd need the tools for compiling resources, etc. Those are all in. mingw32 is quite complete. At the moment, each platform is generating a native for a different build system. But in the cross-compiling scenario, we'd have gyp generate makefiles for everything. - Dan --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
The other thing to remember is the buildbot scripts and a bunch of build scripts on all platforms are full of assumptions about the relationships between projects and the tree. :( TVL On Thu, Jul 23, 2009 at 12:11 PM, Dan Kegel d...@kegel.com wrote: On Thu, Jul 23, 2009 at 9:07 AM, Thomas Van Lententhoma...@chromium.org wrote: Here's my christmas wish: I'd like gyp and chrome to support cross-compilation, so that I could (on my Linux box) kick off distcc-accelerated builds for all three platforms, each one going into a separate objdir. It's not as farfetched as it sounds; Mac can already be built on Linux, I hear, and a Windows build on Linux is within reach (just have to remove the last bits of ATL and apply some elbow grease, I think). A mac build still needs a Mac to drive it. We simply did the work to distribute the compiling to linux also. But the build is driven by xcode, and you need a bunch of other mac tools for the scripts to be able to invoke. OK then, let's make a Mac drive all three builds :-) Window is probably in a similar boat, you'd need the tools for compiling resources, etc. Those are all in. mingw32 is quite complete. At the moment, each platform is generating a native for a different build system. But in the cross-compiling scenario, we'd have gyp generate makefiles for everything. - Dan --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 9:15 AM, Thomas Van Lententhoma...@chromium.org wrote: The other thing to remember is the buildbot scripts and a bunch of build scripts on all platforms are full of assumptions about the relationships between projects and the tree. :( Well, yes. I didn't say it would be easy. I don't even think it's especially likely, but I'd kind of like to avoid changes that make it harder, and I'd like to encourage other people to keep it in mind as they hack on the build machinery. --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 8:53 AM, Evan Martin e...@chromium.org wrote: On Thu, Jul 23, 2009 at 7:47 AM, Nicolas Sylvainnsylv...@chromium.org wrote: gclient has nothing to do with this case. svn update src/ was trying to add a directory called src/bleh, but src/bleh already existed, so svn update failed. Sorry to back-seat drive, but can't you do something like svn status | xargs rm -rf before syncing? (In git it's a builtin: git clean -f to delete all files that aren't officially part of the repository.) I think this could work provided we set svn:ignore properly for directories that gclient inserted into src/. -Darin The only thing gclient might want to do, is clobber your tree, and try again. We used to have stuff like that, but they are all disabled AFAIK, I lost too many important files because gclient wanted to be nice and clean up my machine. I don't understand this paragraph, which might explain why my above proposal is dumb. --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 9:01 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Thu, Jul 23, 2009 at 8:53 AM, Evan Martin e...@chromium.org wrote: On Thu, Jul 23, 2009 at 7:47 AM, Nicolas Sylvainnsylv...@chromium.org wrote: gclient has nothing to do with this case. svn update src/ was trying to add a directory called src/bleh, but src/bleh already existed, so svn update failed. Sorry to back-seat drive, but can't you do something like svn status | xargs rm -rf before syncing? svn status does not show files that are svn:ignore'd, like all generated files should be. Hmm. In creating a clean client, would it make sense to delete all files which exist and are svn:ignore'd? Just as a matter of course? -scott --~--~-~--~~~---~--~~ 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: Design Doc: Adaptive spell checking for multilingual users
Thank you Brian and Paul for your comments and insights. Yes, the plan is to expand to multi-spellcheck simultaneously when the user types in some other language other than the default one, and avoid changing on the fly too often. Paul, I have this feature on hold right now to discuss more issues, and also concentrate on spell check bugs, which need to be squashed before more features (like this one) are crammed in. I have been noticing that you have made some good contributions to spell checking on OS X. If you want, and have time, feel free to grab some spell check bugs and fix them (see http://code.google.com/p/chromium/issues/list?can=2q=sidchat%20status:Assigned%20owner:sidc...@chromium.orgsort=-modifiedcolspec=ID%20Stars%20Pri%20Area%20Type%20Status%20Summary%20Modified%20Owner). Once we have the bugs in control, I will expand the functionality, and you are welcome to port to OS X as appropriate. Thanks, Sid On Jul 22, 10:48 pm, Brian Rakowski br...@chromium.org wrote: I fear that this is treading into territory where the software is trying to be too smart. Most users will type in one language. Many users will type in two languages. Few users will type in more than two languages. A simpler design is simply to notice that the user seems to be multilingual and offer to expand spell check to the additional language(s). I'm concerned that frequent on-the-fly switches will result in incorrect flagging of misspelled words and will irritate users. -Brian On Mon, Jul 20, 2009 at 2:08 PM, Paul Wicks pwick...@gmail.com wrote: Another thing to consider is that something sort of like this is already supported by the OS X spellchecker through the Multilingual language setting. There is currently no way to switch to Multilingual in Chromium on OS X, but it wouldn't be that hard to enable that and it really is something that should be enabled if we want to support the native spelling correction panel on OS X (something which I have about 2/3's done), since the spelling panel shows Multilingual as a language option even if the context menu doesn't. I've done a little bit of experimenting and Multilingual seems to work pretty well in Chromium if you can enable it. One thing that might be a problem is that as far as I can tell, the Multilingual setting just checks all dictionaries for a word, so there could be problems there since a misspelling in the language being used might not be marked if it is a word in another language. I don't think I can say whether chromium is willing to accept Multilingual as the solution for this on OS X. If it is, then what you propose needs to be done in such a way that it doesn't touch the way OS X does this. If this is the solution for all platforms, OS X included, then we need to figure out a way around the spelling panel problem (no matter what, the spelling panel provided by NSSpellChecker will show Multilingual as an option). Whatever is decided, this definitely looks good for the other platforms. If this does go forward, I could probably help out, if you need a hand. -Paul Wicks On Mon, Jul 20, 2009 at 1:00 PM, sidchat sidc...@chromium.org wrote: A new feature to add to the SpellChecker would be its ability to adapt to the user's language of choice when typing in a text box. A design doc can be found at: http://sites.google.com/a/chromium.org/dev/developers/design-document... It will be great if you could go over it and provide suggestions/ improvements, before I move ahead and start implementing this feature as an experiment. -Sid --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Dumping rendered contents to image and identifying objects
Hi, I'm trying to figure out a way to get the rendered contents of a page (such as amazon.com) to dump to an image file (PNG, bitmap or similar), and I also want to be able to identify what objects are being rendered (flash etc.). What would be the best way to approach this? Thanks for your help, Grace --~--~-~--~~~---~--~~ 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: FF's search engine keyword
(cc'ing chromium-discuss, bcc'ing chromium-dev) It is? How do you specify keywords in Chrome's Bookmarks editor? -- Dirk On Wed, Jul 22, 2009 at 12:49 PM, Peter Kastingpkast...@google.com wrote: On Wed, Jul 22, 2009 at 12:46 PM, Igor Gatis igorga...@gmail.com wrote: (please forgive me if this not the right list) It's not. chromium-discuss@ is the right list, or the Help Center. So when I want to google something, I just type g something, when I want to lookup the meaning of a certain word, I just type dc word and so on. Will something like that be supported by chromium? It already is, and furthermore if you imported all your settings from Firefox during install, you have those same keywords set up for you. 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] Mini Installer Build issues
Hi All, My name is Dan here goes my first post to chromium-dev! Anyone else seeing problems building the mini_installer vcproj? I get the following error: 5fatal error RC1110: could not open .\$(IntDir) \mini_installer_exe_version.rc I'm guessing $(IntDir) is an absolute path and its trying to be accessed as if it was a relative path. Let me know if there is a problem with this project or am I possibly doing something wrong. Regards, Dan --~--~-~--~~~---~--~~ 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: Mini Installer Build issues
This kind of error tends to occur if gyp regenerates the project while you are in visual studio.Very often if you close and reopen the solution the problem will go away. Unfortunately hitting yes to project/sln reload does not seem to be equivalent in all cases to a full close and reopen. -BradN On Wed, Jul 22, 2009 at 5:21 PM, Dan Duong dandu...@gmail.com wrote: Hi All, My name is Dan here goes my first post to chromium-dev! Anyone else seeing problems building the mini_installer vcproj? I get the following error: 5fatal error RC1110: could not open .\$(IntDir) \mini_installer_exe_version.rc I'm guessing $(IntDir) is an absolute path and its trying to be accessed as if it was a relative path. Let me know if there is a problem with this project or am I possibly doing something wrong. Regards, Dan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] REMINDER: STRING AND FEATURE FREEZE EOD TOMORROW
Please have any strings you want in the next release in by Friday evening. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA External Phone: 1-650-214-4055 --~--~-~--~~~---~--~~ 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: fighting the flakiness - resource bundle issues?
On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Some of the flaky failures are caused by resource bundle issues. If you are familiar with the build process, or the resource bundle, please take a look. It looks like something needed a manual clobber and didn't get it. 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: fighting the flakiness - resource bundle issues?
To elaborate on Peter's comment. IncrediBuild (which the buildbots use) get confused by changes to our grd files. Our grd files generate headers, which should then cause lots of cc files to get rebuilt. Visual Studio seems to always get this right, but IncrediBuild gets this wrong and cc files don't get rebuilt. I imagine IncrediBuild is checking the timestamp of the file before the headers are re-generated and doesn't realize it needs to rebuild. On Thu, Jul 23, 2009 at 4:38 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Some of the flaky failures are caused by resource bundle issues. If you are familiar with the build process, or the resource bundle, please take a look. It looks like something needed a manual clobber and didn't get it. 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: Compiler warnings?
On Thu, Jul 23, 2009 at 4:30 PM, Wan-Teh Changw...@google.com wrote: Ben, I believe the GCC warning you want is -Wreturn-type, which is enabled if we specify -Wall: http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Warning-Options.html#Warning-Options Are we not compiling with -Wall? Apparently not, which is surprising. -Werror would seem like a good idea, too, though I have not tried it to see how much fixing would be needed. --~--~-~--~~~---~--~~ 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: fighting the flakiness - resource bundle issues?
Is it possible to force it to rebuild some files, or... I don't know, do you see some real way to fix this problem? On Thu, Jul 23, 2009 at 16:41, Tony Chang t...@chromium.org wrote: To elaborate on Peter's comment. IncrediBuild (which the buildbots use) get confused by changes to our grd files. Our grd files generate headers, which should then cause lots of cc files to get rebuilt. Visual Studio seems to always get this right, but IncrediBuild gets this wrong and cc files don't get rebuilt. I imagine IncrediBuild is checking the timestamp of the file before the headers are re-generated and doesn't realize it needs to rebuild. On Thu, Jul 23, 2009 at 4:38 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Some of the flaky failures are caused by resource bundle issues. If you are familiar with the build process, or the resource bundle, please take a look. It looks like something needed a manual clobber and didn't get it. 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: Compiler warnings?
On Thu, Jul 23, 2009 at 4:44 PM, Darin Fisherda...@chromium.org wrote: On Thu, Jul 23, 2009 at 4:42 PM, Ben Laurie b...@google.com wrote: On Thu, Jul 23, 2009 at 4:30 PM, Wan-Teh Changw...@google.com wrote: Ben, I believe the GCC warning you want is -Wreturn-type, which is enabled if we specify -Wall: http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Warning-Options.html#Warning-Options Are we not compiling with -Wall? Apparently not, which is surprising. -Werror would seem like a good idea, too, though I have not tried it to see how much fixing would be needed. What file had the error? (Not all code is compiled with the same warning level.) This was a new file of my own, it lives in src/webkit. -Darin --~--~-~--~~~---~--~~ 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: Compiler warnings?
On Thu, Jul 23, 2009 at 4:50 PM, Ben Laurieb...@google.com wrote: On Thu, Jul 23, 2009 at 4:44 PM, Darin Fisherda...@chromium.org wrote: On Thu, Jul 23, 2009 at 4:42 PM, Ben Laurie b...@google.com wrote: On Thu, Jul 23, 2009 at 4:30 PM, Wan-Teh Changw...@google.com wrote: Ben, I believe the GCC warning you want is -Wreturn-type, which is enabled if we specify -Wall: http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Warning-Options.html#Warning-Options Are we not compiling with -Wall? Apparently not, which is surprising. -Werror would seem like a good idea, too, though I have not tried it to see how much fixing would be needed. What file had the error? (Not all code is compiled with the same warning level.) This was a new file of my own, it lives in src/webkit. Files that tweak -Wall: % git grep -l -e 'Wall' -- '*.gyp*' build/common.gypi build/external_code.gypi From those it appears you need a given .gyp file to opt in to -Wall, by marking it as Chromium code. % git grep -l chromium_code -- '*.gyp' app/app.gyp base/base.gyp build/temp_gyp/googleurl.gyp chrome/app/locales/locales.gyp chrome/chrome.gyp chrome/test/security_tests/security_tests.gyp courgette/courgette.gyp gears/gears.gyp media/media.gyp net/net.gyp net/tools/tld_cleanup/tld_cleanup.gyp o3d/breakpad/breakpad.gyp o3d/build/nacl.gyp o3d/compiler/technique/technique.gyp o3d/converter/converter.gyp o3d/core/core.gyp o3d/import/archive.gyp o3d/import/import.gyp o3d/plugin/idl/idl.gyp o3d/plugin/plugin.gyp o3d/serializer/serializer.gyp o3d/statsreport/statsreport.gyp o3d/tests/tests.gyp o3d/utils/utils.gyp printing/printing.gyp sdch/sdch.gyp views/views.gyp webkit/activex_shim/activex_shim.gyp webkit/activex_shim_dll/activex_shim_dll.gyp webkit/tools/test_shell/test_shell.gyp We could probably do better in webkit.gyp. --~--~-~--~~~---~--~~ 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: Compiler warnings?
Ben, I believe the GCC warning you want is -Wreturn-type, which is enabled if we specify -Wall: http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Warning-Options.html#Warning-Options Are we not compiling with -Wall? Wan-Teh --~--~-~--~~~---~--~~ 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: Compiler warnings?
gcc/g++ have __attribute__((warn_unused_result)) that you can specify on a per-function basis: http://www.ohse.de/uwe/articles/gcc-attributes.html#func-warn_unused_result Or do you mean warnings when a function is supposed to return a value but does not have a return statement at the end? --Mike On Thu, Jul 23, 2009 at 4:09 PM, Ben Laurieb...@google.com wrote: I just fixed a bug that wouldn't have happened at all if missing return values were flagged ... is there a way to turn on compiler warnings (building on Linux using make)? Is there some reason they're not on by default? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] new valgrind mandatory if you use chrome_tests.sh
If you don't run tools/valgrind/chrome_tests.sh, you can ignore this message. tools/valgrind/chrome_tests.sh now uses the --show-possible option to valgrind. This option isn't in standard valgrind, so bad things will happen if you haven't run tools/valgrind/build-valgrind-for-chrome.sh to install our version of valgrind. Symptoms include helpful error messages like unknown option and, for layout tests, unhelpful error messages like test shell crashed. Apologies for the inconvenience. --~--~-~--~~~---~--~~ 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: new valgrind mandatory if you use chrome_tests.sh
On Thu, Jul 23, 2009 at 10:55 PM, Dan Kegeld...@kegel.com wrote: If you don't run tools/valgrind/chrome_tests.sh, you can ignore this message. tools/valgrind/chrome_tests.sh now uses the --show-possible option to valgrind. This option isn't in standard valgrind, so bad things will happen if you haven't run tools/valgrind/build-valgrind-for-chrome.sh to install our version of valgrind. Also: that script installs a symlink to valgrind in /usr/bin. If `which valgrind` doesn't say /usr/bin/valgrind, you may need to futz with your PATH to get the newly installed valgrind to be the default one. --~--~-~--~~~---~--~~ 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: Compiler warnings?
On Thu, Jul 23, 2009 at 4:54 PM, Evan Martine...@chromium.org wrote: On Thu, Jul 23, 2009 at 4:50 PM, Ben Laurieb...@google.com wrote: On Thu, Jul 23, 2009 at 4:44 PM, Darin Fisherda...@chromium.org wrote: On Thu, Jul 23, 2009 at 4:42 PM, Ben Laurie b...@google.com wrote: On Thu, Jul 23, 2009 at 4:30 PM, Wan-Teh Changw...@google.com wrote: Ben, I believe the GCC warning you want is -Wreturn-type, which is enabled if we specify -Wall: http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Warning-Options.html#Warning-Options Are we not compiling with -Wall? Apparently not, which is surprising. -Werror would seem like a good idea, too, though I have not tried it to see how much fixing would be needed. What file had the error? (Not all code is compiled with the same warning level.) This was a new file of my own, it lives in src/webkit. Files that tweak -Wall: % git grep -l -e 'Wall' -- '*.gyp*' build/common.gypi build/external_code.gypi From those it appears you need a given .gyp file to opt in to -Wall, by marking it as Chromium code. % git grep -l chromium_code -- '*.gyp' app/app.gyp base/base.gyp build/temp_gyp/googleurl.gyp chrome/app/locales/locales.gyp chrome/chrome.gyp chrome/test/security_tests/security_tests.gyp courgette/courgette.gyp gears/gears.gyp media/media.gyp net/net.gyp net/tools/tld_cleanup/tld_cleanup.gyp o3d/breakpad/breakpad.gyp o3d/build/nacl.gyp o3d/compiler/technique/technique.gyp o3d/converter/converter.gyp o3d/core/core.gyp o3d/import/archive.gyp o3d/import/import.gyp o3d/plugin/idl/idl.gyp o3d/plugin/plugin.gyp o3d/serializer/serializer.gyp o3d/statsreport/statsreport.gyp o3d/tests/tests.gyp o3d/utils/utils.gyp printing/printing.gyp sdch/sdch.gyp views/views.gyp webkit/activex_shim/activex_shim.gyp webkit/activex_shim_dll/activex_shim_dll.gyp webkit/tools/test_shell/test_shell.gyp We could probably do better in webkit.gyp. Not surprisingly, adding that to webkit.gyp breaks things :-) I could look at a patch for that if people think its wise. --~--~-~--~~~---~--~~ 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: Compiler warnings?
On Thu, Jul 23, 2009 at 4:17 PM, Mike Mammarellam...@chromium.org wrote: gcc/g++ have __attribute__((warn_unused_result)) that you can specify on a per-function basis: http://www.ohse.de/uwe/articles/gcc-attributes.html#func-warn_unused_result Or do you mean warnings when a function is supposed to return a value but does not have a return statement at the end? Indeed, that is what I mean. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] fighting the flakiness - resource bundle issues?
Some of the flaky failures are caused by resource bundle issues. If you are
familiar with the build process, or the resource bundle, please take a look.
I'm pasting relevant parts of the logs:
C:\b\slave\chromium-dbg-builder\build\src\chrome\test\ui\ui_test.cc(227):
error: Value of: server_-WaitForInitialLoads()
Actual: false
Expected: true
C:\b\slave\chromium-dbg-builder\build\src\chrome\test\ui\ui_test.cc(161):
error: Value of: assertions.size()
Actual: 1
Expected: expected_errors_
Which is: 0
The following error(s) occurred in the application during this test:
[FATAL:resource_bundle.cc(142)] Check failed: false.
C:\b\slave\chromium-dbg-builder\build\src\chrome\test\ui\ui_test.cc(175):
error: Value of: actual_crashes
Actual: 1
Expected: expected_crashes_
Which is: 0
Encountered an unexpected crash in the program during this test.
It seems to be hit in this code:
// We failed to retrieve the bitmap, show a debugging red square.
{
LOG(WARNING) Unable to load bitmap with id resource_id;
NOTREACHED(); // Want to assert in debug mode.
AutoLock lock_scope(lock_); // Guard empty_bitmap initialization.
static SkBitmap* empty_bitmap = NULL;
if (!empty_bitmap) {
// The placeholder bitmap is bright red so people notice the problem.
// This bitmap will be leaked, but this code should never be hit.
empty_bitmap = new SkBitmap();
empty_bitmap-setConfig(SkBitmap::kARGB__Config, 32, 32);
empty_bitmap-allocPixels();
empty_bitmap-eraseARGB(255, 255, 0, 0);
}
return empty_bitmap;
}
--~--~-~--~~~---~--~~
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: fighting the flakiness - resource bundle issues?
Look at how the current gyp hook works. It looks for changes to .gyp files and only runs if a .gyp (and maybe gypi?) file has changed. You can find what header it generates by opening the grd file and parsing the XML (the XML lists the output files). You'll need to build the base directory (e.g., Debug/obj/global_intermediate/ and the Release version), I would just check for the Windows versions since we don't seem to have this problem with the mac or linux buildbots. On Thu, Jul 23, 2009 at 5:36 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I think that this workaround may be worth it. I'm not familiar with the IncrediBuild, but I can help making the hook (and we can run it only on Windows). How do I make a hook know which grd files changed? And also know which headers it generates? Alternatively, maybe this Windows-only hook would just delete all generated headers (with a hardcoded list)? Generation seems to be cheap, and such hook seems trivial to write. So, yes, this hook is kludgey. But we are aware of its limitations, and it would eliminate one kind of build mysteries. What do you think? On Thu, Jul 23, 2009 at 17:30, Tony Chang t...@chromium.org wrote: Here's a crappy work around: Add a gclient hook that checks for grd file changes. When a grd file changes, force delete the header it would generate. I'm pretty sure this would prevent bad builds from IncrediBuild. Alternately, maybe we can make a reduced test case and file a bug against IncrediBuild. On Thu, Jul 23, 2009 at 4:44 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Is it possible to force it to rebuild some files, or... I don't know, do you see some real way to fix this problem? On Thu, Jul 23, 2009 at 16:41, Tony Chang t...@chromium.org wrote: To elaborate on Peter's comment. IncrediBuild (which the buildbots use) get confused by changes to our grd files. Our grd files generate headers, which should then cause lots of cc files to get rebuilt. Visual Studio seems to always get this right, but IncrediBuild gets this wrong and cc files don't get rebuilt. I imagine IncrediBuild is checking the timestamp of the file before the headers are re-generated and doesn't realize it needs to rebuild. On Thu, Jul 23, 2009 at 4:38 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Some of the flaky failures are caused by resource bundle issues. If you are familiar with the build process, or the resource bundle, please take a look. It looks like something needed a manual clobber and didn't get it. 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] Compiler warnings?
I just fixed a bug that wouldn't have happened at all if missing return values were flagged ... is there a way to turn on compiler warnings (building on Linux using make)? Is there some reason they're not on by default? --~--~-~--~~~---~--~~ 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: fighting the flakiness - resource bundle issues?
I think that this workaround may be worth it. I'm not familiar with the IncrediBuild, but I can help making the hook (and we can run it only on Windows). How do I make a hook know which grd files changed? And also know which headers it generates? Alternatively, maybe this Windows-only hook would just delete all generated headers (with a hardcoded list)? Generation seems to be cheap, and such hook seems trivial to write. So, yes, this hook is kludgey. But we are aware of its limitations, and it would eliminate one kind of build mysteries. What do you think? On Thu, Jul 23, 2009 at 17:30, Tony Chang t...@chromium.org wrote: Here's a crappy work around: Add a gclient hook that checks for grd file changes. When a grd file changes, force delete the header it would generate. I'm pretty sure this would prevent bad builds from IncrediBuild. Alternately, maybe we can make a reduced test case and file a bug against IncrediBuild. On Thu, Jul 23, 2009 at 4:44 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Is it possible to force it to rebuild some files, or... I don't know, do you see some real way to fix this problem? On Thu, Jul 23, 2009 at 16:41, Tony Chang t...@chromium.org wrote: To elaborate on Peter's comment. IncrediBuild (which the buildbots use) get confused by changes to our grd files. Our grd files generate headers, which should then cause lots of cc files to get rebuilt. Visual Studio seems to always get this right, but IncrediBuild gets this wrong and cc files don't get rebuilt. I imagine IncrediBuild is checking the timestamp of the file before the headers are re-generated and doesn't realize it needs to rebuild. On Thu, Jul 23, 2009 at 4:38 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Some of the flaky failures are caused by resource bundle issues. If you are familiar with the build process, or the resource bundle, please take a look. It looks like something needed a manual clobber and didn't get it. 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: fighting the flakiness - resource bundle issues?
Here's a crappy work around: Add a gclient hook that checks for grd file changes. When a grd file changes, force delete the header it would generate. I'm pretty sure this would prevent bad builds from IncrediBuild. Alternately, maybe we can make a reduced test case and file a bug against IncrediBuild. On Thu, Jul 23, 2009 at 4:44 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Is it possible to force it to rebuild some files, or... I don't know, do you see some real way to fix this problem? On Thu, Jul 23, 2009 at 16:41, Tony Chang t...@chromium.org wrote: To elaborate on Peter's comment. IncrediBuild (which the buildbots use) get confused by changes to our grd files. Our grd files generate headers, which should then cause lots of cc files to get rebuilt. Visual Studio seems to always get this right, but IncrediBuild gets this wrong and cc files don't get rebuilt. I imagine IncrediBuild is checking the timestamp of the file before the headers are re-generated and doesn't realize it needs to rebuild. On Thu, Jul 23, 2009 at 4:38 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Some of the flaky failures are caused by resource bundle issues. If you are familiar with the build process, or the resource bundle, please take a look. It looks like something needed a manual clobber and didn't get it. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
