[chromium-dev] Re: checkdeps failure when a unit test relies on v8.h
the js debugger On Mon, Feb 16, 2009 at 5:53 AM, Dean McNamee de...@chromium.org wrote: What for? On Mon, Feb 16, 2009 at 12:18 AM, Erik Kay erik...@chromium.org wrote: v8 is already in the browser process. Erik On Sun, Feb 15, 2009 at 1:46 PM, Evan Martin e...@chromium.org wrote: Does this mean we'll have v8 in the browser process? We had idly chatted about running a 64-bit browser process to fix the library hell on Linux. It shouldn't block you either way -- I'm just curious. On Sun, Feb 15, 2009 at 1:42 AM, Aaron Boodman a...@chromium.org wrote: I'm trying to commit a change (http://codereview.chromium.org/19737/diff/1440/1448 ) which adds a base class for unit tests that exercise JavaScript. It uses v8.h, which is disallowed by DEPS. What is the right way to do this? - 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: checkdeps failure when a unit test relies on v8.h
I thought the js debugger was out of process (or trying to be)? On Mon, Feb 16, 2009 at 1:29 PM, Marc-Antoine Ruel mar...@chromium.org wrote: the js debugger On Mon, Feb 16, 2009 at 5:53 AM, Dean McNamee de...@chromium.org wrote: What for? On Mon, Feb 16, 2009 at 12:18 AM, Erik Kay erik...@chromium.org wrote: v8 is already in the browser process. Erik On Sun, Feb 15, 2009 at 1:46 PM, Evan Martin e...@chromium.org wrote: Does this mean we'll have v8 in the browser process? We had idly chatted about running a 64-bit browser process to fix the library hell on Linux. It shouldn't block you either way -- I'm just curious. On Sun, Feb 15, 2009 at 1:42 AM, Aaron Boodman a...@chromium.org wrote: I'm trying to commit a change (http://codereview.chromium.org/19737/diff/1440/1448 ) which adds a base class for unit tests that exercise JavaScript. It uses v8.h, which is disallowed by DEPS. What is the right way to do this? - 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: linux: the views situation
On 5 fév, 05:27, Ben Goodger (Google) b...@chromium.org wrote: In general, we've avoided cross platform UI toolkits because while they may offer what superficially appears to be a quick path to native looking UI on a variety of target platforms, once you go a bit deeper it turns out to be a bit more problematic. As Amanda says, your app ends up speaking with a foreign accent. Our experience is that using these frameworks also limits what you can do to a lowest common denominator subset of what's supported by that framework on each platform. My initial thought was that a Windows-clone would be acceptable on Linux provided the performance of the app itself was outstanding, given the general reluctance of some of the team working on Linux towards UI. But they stood up and made their case for a GTK UI, and so if you read the other thread on this topic posted to this list yesterday, you'll see that that's what we've decided to do. A Windows-clone would most definitely not be acceptable on MacOS X, where the APIs for UI development are highly evolved and have many outstanding features. So that's always been the plan there. views is still theoretically portable, but it's unlikely we'll ever use this capability. The architecture of Chrome has converged over the past few months on a solid separation of view from state, and this has given us the flexibility to make these decisions and choose from the widest range of alternatives. -BenOn Wed, Feb 4, 2009 at 8:20 PM, Peter Petrov onest...@gmail.com wrote: This thread sounds really scary. Although it was initially claimed that Chrome was designed to be cross-platform from the ground up, it's obviously full of windows-isms at almost every level. Now it seems you will be forced to maintain a separate UI port for each platform. I sincerely wonder, why didn't you just use Qt for the UI from the beginning? It blends very well with the native lookfeel on each platform, while still letting you implement the distinctive Chrome features. Qt 4.5 will even have native look in GNOME. I agree with Peter Petrov. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Windows builds will need a clobber for rev 9859
Hi All, Because the latest merge brought down a change to CSSNames.in (http://trac.webkit.org/changeset/40939), all those of us building on Windows will need to clobber: delete your build directory and start with a clean build. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] eliminating build/build_config.h -- need help on mac
A few people I've talked to independently have expressed interest in getting rid of build/build_config.h. It is easy to forget to include, requires being included in a nonstandard place, and ends up being used everywhere anyway. It is easier to just define the few #defines we need in build scripts. (I think the compiler- and architecture- specific defines could move to a different file eventually, but we almost never use those.) http://codereview.chromium.org/21401 does this. It seems to work on Windows (I'd like an expert to doublecheck I did it the right way) but my wild guess at making Mac work is apparently wrong. If any Mac expert could help out, I'd appreciate it. --~--~-~--~~~---~--~~ 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: eliminating build/build_config.h -- need help on mac
On Mon, Feb 16, 2009 at 1:45 PM, Evan Martin e...@chromium.org wrote: http://codereview.chromium.org/21401 does this. It seems to work on Windows (I'd like an expert to doublecheck I did it the right way) but my wild guess at making Mac work is apparently wrong. If any Mac expert could help out, I'd appreciate it. I support the idea of getting rid of build_config.h as an explicit include. However, build_config.h defines more than just OS_XXX. Why not pass -include ../build/build_config.h to GCC? AGL --~--~-~--~~~---~--~~ 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: eliminating build/build_config.h -- need help on mac
On Mon, Feb 16, 2009 at 4:00 PM, Adam Langley a...@chromium.org wrote: On Mon, Feb 16, 2009 at 1:45 PM, Evan Martin e...@chromium.org wrote: http://codereview.chromium.org/21401 does this. It seems to work on Windows (I'd like an expert to doublecheck I did it the right way) but my wild guess at making Mac work is apparently wrong. If any Mac expert could help out, I'd appreciate it. I support the idea of getting rid of build_config.h as an explicit include. However, build_config.h defines more than just OS_XXX. Why not pass -include ../build/build_config.h to GCC? My reasoning was that we don't want to litter the preprocessor namespace with defines, and the OS_* ones are 99% of the reason to include the header. My (implied) plan was that build_config.h could become compiler_config.h or whatever once it's seen where it's 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: eliminating build/build_config.h -- need help on mac
I don't agree with this approach. I think that we should include what we use, and that should extend to headers that provide nonstandard macro definitions. I think that we should be expressing as much as possible in code rather than in build environments. Most importantly, I don't like the idea of globally polluting the macro namespace for something like this. Our OS_* macros are ours (emphasis on ours) and I don't want to leak those defines to all of the other third-party code that we build. Mark Evan Martin wrote: A few people I've talked to independently have expressed interest in getting rid of build/build_config.h. It is easy to forget to include, requires being included in a nonstandard place, and ends up being used everywhere anyway. It is easier to just define the few #defines we need in build scripts. (I think the compiler- and architecture- specific defines could move to a different file eventually, but we almost never use those.) http://codereview.chromium.org/21401 does this. It seems to work on Windows (I'd like an expert to doublecheck I did it the right way) but my wild guess at making Mac work is apparently wrong. If any Mac expert could help out, I'd appreciate it. --~--~-~--~~~---~--~~ 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: Writing tips to our build instructions?
Hey there, This wiki is open to anyone to edit, http://code.google.com/p/chromium/wiki/MacBuildInstructions It is linked directly from: http://dev.chromium.org/developers I have seen the IRC log :) Many people are having this issue, would be great to update it so future coders wont run into the same problems. On Mon, Feb 16, 2009 at 11:54 PM, Hironori Bono (坊野 博典) hb...@chromium.orgwrote: Hi Chromium developers, Today, I noticed a person who could not build Chromium (on Mac OS X) because he/she downloaded the source code of Chromium to a directory which contains space characters (e.g. ~/Mac OS X/chromium). Even though I'm not sure this is a known issue, I would like to note this to somewhere in our build instructions if not. Is it possible to give me good places to write such build tips? Regards, Hironori Bono E-mail: hb...@chromium.org --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
