[chromium-dev] Re: NSS and NSPR
I realize our checkouts are big, but there is a ton of other stuff besides NSS. I don't really see the point in trying to do this just now, it's seems likely to break a bunch of other platforms and be a bit of a mess. If you feel that it's that important, ok, don't break anything :) On Thu, Feb 26, 2009 at 8:36 AM, Darin Fisher da...@chromium.org wrote: Hmm... I'm OK with having the small duplication of NSS/NSPR code for the foreseeable future. I think it is nice that base doesn't require all of NSS+NSPR. So, I guess that's a +1 in favor of moving it to deps_os as planned. -Darin On Wed, Feb 25, 2009 at 9:08 PM, Michael Moss mm...@chromium.org wrote: Does that imply that it shouldn't move to deps? We can restrict it to Linux with deps_os now, and then make it apply to all platforms later, right? Or is it better to just leave it in trunk since it's already there? I'm fine with it either way, though it's less hassle for me to leave it where it is, and it means it's in my git tree instead of gclient/svn, but that's only a minor benefit since I don't expect to be changing it a lot once all these initial commits are in. Michael On Wed, Feb 25, 2009 at 8:08 PM, Darin Fisher da...@chromium.org wrote: If we do that cleanup, then we will need NSS and NSPR on all platforms. -Darin On Wed, Feb 25, 2009 at 7:31 PM, Michael Moss mm...@chromium.org wrote: There are actually both nss and nspr under base, but only a handful of files, not the whole trees. I plan to clean those up as appropriate, once this is all in and working. Michael On Wed, Feb 25, 2009 at 5:15 PM, Lei Zhang thes...@chromium.org wrote: BTW, we have both src/third_party/nss/ and src/base/third_party/nss/. On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten thoma...@chromium.org wrote: Sorry for arriving late w/ this question... I'm guessing NSS NSPR are needed for the linux build? Should they be pulled in via DEPS instead of being directly in src/third_party? In the current form it causes both mac and windows to have to add ~80M to their svn trees that really isn't needed. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] mac builds
Mac builds will probably need to either clobber or nuke src/xcodebuild/chrome.build/*/generated. I landed support for the resource loader, but you need the grit based resources to rebuild, and xcode deps doesn't currently track as dependencies any changes to the scripts that build them. TVL --~--~-~--~~~---~--~~ 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: NSS and NSPR
By the way, since this apparently hasn't been discussed as widely as I had thought, here's a little background on this new nss/nspr stuff. We currently build Linux Chromium with the system nss and nspr libraries. This works fine for most 32-bit distros, since these are standard packages, and that allows us to leverage the distro for critical security updates. This functionality is not going away; it will still be possible to build against the system versions of these libs, and this is how we expect distro maintainers will build their packages. However, our own target platform of 64-bit Ubuntu Hardy doesn't provide these libraries in 32-bit form, so Chromium won't run on an unmodified version of that distro (note the hoops our Linux development instructions jump through to setup a build machine). To support dogfooding on our target platform, and to provide a compatibility option for 64-bit distros in general, we decided to include nss and nspr directly in our build, thus bypassing any issues with missing system libs. Michael On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten thoma...@chromium.org wrote: Sorry for arriving late w/ this question... I'm guessing NSS NSPR are needed for the linux build? Should they be pulled in via DEPS instead of being directly in src/third_party? In the current form it causes both mac and windows to have to add ~80M to their svn trees that really isn't needed. TVL --~--~-~--~~~---~--~~ 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: NSS and NSPR
On Thu, Feb 26, 2009 at 9:26 AM, Michael Moss mm...@chromium.org wrote: include nss and nspr directly in our build, thus bypassing any issues with missing system libs. Also note that, for the people using git, it's all in the history now anyway so it doesn't matter to us if it ever gets removed. 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: NSS and NSPR
I don't understand why we need to import all of this code just so we can build an .so. Why don't we just take the .so's from the 32-bit package we're already using, and stick them into our .deb? We can check them into svn if don't want developers to have to have it, but that problem is already solved by the install script. Tracking third_party source (security updates, etc) is a huge pain, and has caused a lot of problems in the past. Also, having to build it seems pointless. On Thu, Feb 26, 2009 at 6:42 PM, Adam Langley a...@chromium.org wrote: On Thu, Feb 26, 2009 at 9:26 AM, Michael Moss mm...@chromium.org wrote: include nss and nspr directly in our build, thus bypassing any issues with missing system libs. Also note that, for the people using git, it's all in the history now anyway so it doesn't matter to us if it ever gets removed. 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: NSS and NSPR
This would certainly make things a lot easier. One issue I can think of is that we currently bundle a modified sqlite, and nss uses sqlite. Part of the plan was for our bundled nss to use our sqlite (since that's another 32-bit lib which is missing on Hardy). We can still do this with borrowed .so's, but I'm not sure if our changes to sqlite would have any implications for nss compiled against a different version (someone more familiar with our sqlite changes might know if this is an issue or not). Michael On Thu, Feb 26, 2009 at 9:48 AM, Dean McNamee de...@chromium.org wrote: I don't understand why we need to import all of this code just so we can build an .so. Why don't we just take the .so's from the 32-bit package we're already using, and stick them into our .deb? We can check them into svn if don't want developers to have to have it, but that problem is already solved by the install script. Tracking third_party source (security updates, etc) is a huge pain, and has caused a lot of problems in the past. Also, having to build it seems pointless. On Thu, Feb 26, 2009 at 6:42 PM, Adam Langley a...@chromium.org wrote: On Thu, Feb 26, 2009 at 9:26 AM, Michael Moss mm...@chromium.org wrote: include nss and nspr directly in our build, thus bypassing any issues with missing system libs. Also note that, for the people using git, it's all in the history now anyway so it doesn't matter to us if it ever gets removed. 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: NSS and NSPR
On Thu, Feb 26, 2009 at 10:03 AM, Wan-Teh Chang w...@google.com wrote: On Thu, Feb 26, 2009 at 9:48 AM, Dean McNamee de...@chromium.org wrote: I don't understand why we need to import all of this code just so we can build an .so. Why don't we just take the .so's from the 32-bit package we're already using, and stick them into our .deb? We can check them into svn if don't want developers to have to have it, but that problem is already solved by the install script. Tracking third_party source (security updates, etc) is a huge pain, and has caused a lot of problems in the past. Also, having to build it seems pointless. This idea also occurred to me. Chromium only needs the NSS/NSPR headers and the .so's for Linux. The only issue is that the NSS/NSPR .so's we check into the source tree need to work on all x86 Linux distributions that we support. I don't know the state of binary compatibility across Linux distributions today. Perhaps it works -- I believe that's how Adobe distributes its Flash plugins. Another idea is to work harder with Ubuntu to provide the ia32 NSPR/NSS libs for x86_64 in Ubuntu 8.04 LTS. That'd be the best solution but require a lot of red tape. For those who haven't been following this whole saga, note that there is an Ubuntu bug for this, and so far they have been unwilling to backport it to Hardy. They applied a fix (unfortunately broken) to Intrepid, but don't seem inclined to muck with Hardy unless it's a security fix. At this point, any new requests would be targeted to Jaunty by default. Michael --~--~-~--~~~---~--~~ 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: NSS and NSPR
On Thu, Feb 26, 2009 at 10:14 AM, Adam Langley a...@chromium.org wrote: On Thu, Feb 26, 2009 at 10:10 AM, Michael Moss mm...@chromium.org wrote: For those who haven't been following this whole saga, note that there is an Ubuntu bug for this, and so far they have been unwilling to backport it to Hardy. They applied a fix (unfortunately broken) to Intrepid, but don't seem inclined to muck with Hardy unless it's a security fix. At this point, any new requests would be targeted to Jaunty by default. As I understand it, NSS must be built as a .so, at least in part. Since we cannot statically link NSS, I don't believe it should be in our tree. Since we're already going to provide packages for 32-bit systems, we can also provide a libnss-32 (or whatever) package and make chromium-browser depend on that. The main problem with that is that it might conflict with distros that already have some or all of the 32-bit stuff (e.g. Intrepid). If we depend on lib32nss2, to get /usr/lib32/libnss3.so, but the distro supplies that in ia32-libs (as it normally would), then our dependency will conflict with ia32-libs and chromium-browser won't install. --~--~-~--~~~---~--~~ 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: NSS and NSPR
On Thu, Feb 26, 2009 at 10:27 AM, Michael Moss mm...@chromium.org wrote: The main problem with that is that it might conflict with distros that already have some or all of the 32-bit stuff (e.g. Intrepid). If we depend on lib32nss2, to get /usr/lib32/libnss3.so, but the distro supplies that in ia32-libs (as it normally would), then our dependency will conflict with ia32-libs and chromium-browser won't install. We'll have different repos for each different supported release and distribution anyway, so I don't believe this is a problem. 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: NSS and NSPR
On Thu, Feb 26, 2009 at 10:29 AM, Adam Langley a...@chromium.org wrote: On Thu, Feb 26, 2009 at 10:27 AM, Michael Moss mm...@chromium.org wrote: The main problem with that is that it might conflict with distros that already have some or all of the 32-bit stuff (e.g. Intrepid). If we depend on lib32nss2, to get /usr/lib32/libnss3.so, but the distro supplies that in ia32-libs (as it normally would), then our dependency will conflict with ia32-libs and chromium-browser won't install. We'll have different repos for each different supported release and distribution anyway, so I don't believe this is a problem. Actually, right now, we don't. Our other app packages are universal (within the realm of our supported platforms). Michael --~--~-~--~~~---~--~~ 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: NSS and NSPR
On Thu, Feb 26, 2009 at 10:54 AM, Michael Moss mm...@chromium.org wrote: On Thu, Feb 26, 2009 at 10:40 AM, Dean McNamee de...@chromium.org wrote: We don't need to stick the .so's in /usr/lib32 then do we? We can stick them in our own directory if that's the concern. I don't understand have this relates to building our own .so's or reusing someone elses, since either way you have the problem of us shipping one, and someone might already have one. I think we're in agreement here, but I was more just arguing against the separate package dependency. If it's installing to our directory, it might as well not be a separate package. Spoke to soon. One instance where a separate package in our directory would make sense is if ia32-libs eventually adds the needed libs. The chromium-browser package would depend on either our lib32nss3 OR ia32-libs = whatever the known good version is. This would avoid installing our lib32nss3 on systems we know don't need it, while not conflicting with ia32-libs that provide some of the necessary libs. Michael --~--~-~--~~~---~--~~ 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: NSS and NSPR
On Thu, Feb 26, 2009 at 10:40 AM, Dean McNamee de...@chromium.org wrote: We don't need to stick the .so's in /usr/lib32 then do we? We can stick them in our own directory if that's the concern. I don't understand have this relates to building our own .so's or reusing someone elses, since either way you have the problem of us shipping one, and someone might already have one. I think we're in agreement here, but I was more just arguing against the separate package dependency. If it's installing to our directory, it might as well not be a separate package. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Histogram support is now provided it the Renderer processes as well as the browser process
If you're not chasing after performance and stats issues in the renderer, you can stop reading now. Thanks to the work by Raman Tenneti, the support for histograms that has been available in the Browser process, is now provided in the Renderer processes. Histograms gathered in Renderers are automatically aggregated up into Browser process for viewing and/or UMA uploading. Typical complexities of usage is hidden in a macro that declares and reuses a static initializer (to make this code very fast, and aside from the first call creating the static, effectively thread safe). A sample usage would be: #include base/histogram.h ... base::TimeTicks start_time = base::TimeTicks::Now(); // Do something, or some tasks, that take a while (few milliseconds?? few minutes?) HISTOGRAM_TIMES(YourGroup.TimeToDoFooTask, base::TimeTicks::Now() - start_time); You can then see all the histograms created in your Chromium run by visiting: about:histograms You'll probably see that there are a LOT already. IF you want to see your specific histograms (only) look at: about:histograms/YourGroup or about:histograms/YourGroup.TimeToDoFooTask or about:histograms/FooTask etc. As one other example, if you were trying to count (for example) how many times something interesting happened in a page, you might use: HISTOGRAM_COUNTS(YourGroup.GoobersPerPage, goober_count); Lastly, if you're just doing this for personal/private debugging development, please use the DHISTOGRAM_TIMES and DHISTOGRAM_COUNTS etc. macros, which are not compiled into the final release binary (moral equivalent of DCHECK vs CHECK). Additional flavors are available for consideration in base/histogram.h Enjoy, Jim p.s., This should transparently work in single process mode as well. --~--~-~--~~~---~--~~ 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: Let's make build system history!
Matt Perry wrote: Does this mean the checked-in xcode project files are obsolete? Not yet, but they will be soon. Or do we need to update both .gyp and .xcodeproj files now? If you only update one, it has to be the checked-in .xcodeproj for now. That's still the official build for the Mac. Ideally you'd update the .gyp too and Cc me on the review. You don't have to wait for a response from me for simple changes, I just want to keep tabs on what's changing because I'm still working pretty heavily on some parts. The more that people start updating .gyp files when they change things now, the less I'll have to play catch-up. That leaves me with more time to finish the actual conversion so that we can svn remove the old xcodeprojs and switch to GYP-only on the Mac. I think that this is in everyone's best interest, but especially mine. 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: linux async IO
2009/2/26 Dean McNamee de...@chromium.org: Hey Will, I'd suggest as a first step improving the WorkerPool. It should be pretty easy, I don't think it will hurt us to do something where we fire off threads on demand, but then keep them around and reuse them. Might need some timer to periodically destroy idle threads when we get too many, etc. That's a pretty self contained change and would be a good first review. After that it will make more sense to implement the network file code to post tasks to the worker pool, and just do blocking IO there. That sounds reasonable to me. Also, do you have some page cycler numbers now and some oprofile data? I'd like to see the hot spots and where we are blocking on file access. This will be great data for comparison to the async implementation and make sure that we did indeed address all of the places we were concerned about. Nope, I don't know if it runs yet. I think Darin told me that there was some bug on linux or mac or both where it fails to run. I'm not sure. I agree the data is useful. I'll see if I can get any numbers. Thanks -- dean 2009/2/26 Craig Schlenter craig.schlen...@gmail.com: On Wed, Feb 25, 2009 at 11:21 PM, Adam Langley a...@chromium.org wrote: On Wed, Feb 25, 2009 at 1:13 PM, William Chan (陈智昌) willc...@chromium.org wrote: I talked to Darin and he told me that this needs work since it's impacting the page cycler times, so I figured I'd pick it up. You have a TODO there saying to figure out how to best do async IO. Did you ever figure this out? I talked to Darin briefly and decided that the simplest thing to do for now is simply to post tasks to the global WorkerPool. The global WorkerPool linux implementation looks pretty silly and needs work, but it's probably good enough for the page cycler. How does this approach sound to you? It's not clear if you were considering using POSIX async IO on Linux or not. Just in case you were: don't. It mostly doesn't work. LWN has a nice article on the future of async IO on linux here btw. http://lwn.net/Articles/316806/ Unfortunately that's not that useful currently. --Craig --~--~-~--~~~---~--~~ 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: Histogram support is now provided it the Renderer processes as well as the browser process
It would be cool if some of this histogram wisdom (like how adding the /FooTask filters) was up on our dev site somewhere. I always forget how to do filtering... On Thu, Feb 26, 2009 at 11:02 AM, Jim Roskind j...@chromium.org wrote: If you're not chasing after performance and stats issues in the renderer, you can stop reading now. Thanks to the work by Raman Tenneti, the support for histograms that has been available in the Browser process, is now provided in the Renderer processes. Histograms gathered in Renderers are automatically aggregated up into Browser process for viewing and/or UMA uploading. Typical complexities of usage is hidden in a macro that declares and reuses a static initializer (to make this code very fast, and aside from the first call creating the static, effectively thread safe). A sample usage would be: #include base/histogram.h ... base::TimeTicks start_time = base::TimeTicks::Now(); // Do something, or some tasks, that take a while (few milliseconds?? few minutes?) HISTOGRAM_TIMES(YourGroup.TimeToDoFooTask, base::TimeTicks::Now() - start_time); You can then see all the histograms created in your Chromium run by visiting: about:histograms You'll probably see that there are a LOT already. IF you want to see your specific histograms (only) look at: about:histograms/YourGroup or about:histograms/YourGroup.TimeToDoFooTask or about:histograms/FooTask etc. As one other example, if you were trying to count (for example) how many times something interesting happened in a page, you might use: HISTOGRAM_COUNTS(YourGroup.GoobersPerPage, goober_count); Lastly, if you're just doing this for personal/private debugging development, please use the DHISTOGRAM_TIMES and DHISTOGRAM_COUNTS etc. macros, which are not compiled into the final release binary (moral equivalent of DCHECK vs CHECK). Additional flavors are available for consideration in base/histogram.h Enjoy, Jim p.s., This should transparently work in single process mode as well. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Frame Switching
Chrome has a long-standing bug due to the design of its frames where when you toggle DWM on and off on Vista the app is rendered unusable due to the top area of the browser window being rendered black. This is because the display mode it was using is suddenly changed out from under it and some assumptions that exist no longer hold true. With MagicBrowzr, the theory was we could solve this by allowing the content of the BrowserView to be re-parented into a new window of the correct frame type when the DWM is toggled. With some experimentation though it's become clear this is slightly problematic: - lots of views assume they're only inserted into a view hierarchy once, and thus re-run init code when this happens which sometimes has harmful effects - there is an undesirable animation as the DWM replacement window is opened/closed With some thought, I've come to thinking that having a separate class for the custom frame window from the regular non-custom frame window is problematic, because this is the only reason we need to swap frames. I am thinking it might be better to coalesce these two types, since one is a strict subset of another, and just have a mode on the object that indicates it's using a custom frame. Then when we switch DWM off we can toggle the mode and avoid some of these gymnastics. -Ben --~--~-~--~~~---~--~~ 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: Frame Switching
On Thu, Feb 26, 2009 at 1:04 PM, Ben Goodger (Google) b...@chromium.orgwrote: I am thinking it might be better to coalesce these two types, since one is a strict subset of another, and just have a mode on the object that indicates it's using a custom frame. Then when we switch DWM off we can toggle the mode and avoid some of these gymnastics. That's doable. It will be a bit tricky but not too bad. I could probably pull it off for you if you want, I'm pretty familiar with that code now :) 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] earn money online $50,$60,$75 no sign up fees !its really easy
make money through online click this link and earn money online http://www.AWSurveys.com/HomeMain.cfm?RefID=nimisha --~--~-~--~~~---~--~~ 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] converting some notimplemented()s into bugs
Ok, we're now down to around 25 error messages on startup, many of which are things people are working on. Don't be afraid to convert other minor stuff into P3 bugs and remove the NOTIMPLEMENTEDs. On Wed, Feb 25, 2009 at 2:16 PM, Evan Martin e...@chromium.org wrote: As we get closer to something stable, it's helpful to not have real error messages masked by console spew about bits we don't especially care about yet. For example, we currently output this on startup: [4635:4635:1130873151532:ERROR:browser/process_singleton_linux.cc(60)] Not implemented reached in void ProcessSingleton::HuntForZombieChromeProcesses() That function on Windows attempts to, during startup, find previous instances of Chrome that have hung and kill them if necessary. Maybe it'd be a good idea for us to have something similar (if it's even possible to judge whether the other processes are hung) but it is not helpful right now. I suggest removing such calls to NOTIMPEMENTED() and converting them into bugs. A good heuristic is if it would be filed as a low-priority bug if the code didn't work, then it's probably safe to make it into a low-priority bug now. (Don't forget the os:linux label if appropriate.) Large NOTIMPLEMENTEDs that represent real holes, like those that will cause crashes or our missing support for keyboard accelerators, are better to leave in the code for now. Use your judgement. --~--~-~--~~~---~--~~ 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: Frame Switching
I'll take care of the first iteration. There are a few things here that I know I want to do but I don't know what they all are yet. -Ben On Thu, Feb 26, 2009 at 1:06 PM, Peter Kasting pkast...@google.com wrote: On Thu, Feb 26, 2009 at 1:04 PM, Ben Goodger (Google) b...@chromium.org wrote: I am thinking it might be better to coalesce these two types, since one is a strict subset of another, and just have a mode on the object that indicates it's using a custom frame. Then when we switch DWM off we can toggle the mode and avoid some of these gymnastics. That's doable. It will be a bit tricky but not too bad. I could probably pull it off for you if you want, I'm pretty familiar with that code now :) 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] checked in file third_party/libxml/win32/include/xmlversion.h [Attn: Daniel Veillard]
Hello I am trying to integrate test a third party library available in source into the Visual Studio 2008 Pro environment. The problem seems to be that the third_party/libxml/win32/include/xmlversion.h file defines LIBXML_ICU_ENABLED. This causes encoding.h to include unicode/ucnv.h which seems unavailable on Windows. So either I #ifdef around the third party library source but that would be a bad hack. So the question is should LIBXML_ICU_ENABLED be defined in third_party/ libxml/win32/include/xmlversion.h . My guess is that someone used cygwin to generate this xmlversion.h. Can someone please throw some light on this? Perhaps Daniel Veillard could comment. Thanks --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: checked in file third_party/libxml/win32/include/xmlversion.h [Attn: Daniel Veillard]
On Thu, Feb 26, 2009 at 7:59 PM, eager_learner vijay.sankar.ra...@gmail.com wrote: Hello I am trying to integrate test a third party library available in source into the Visual Studio 2008 Pro environment. The problem seems to be that the third_party/libxml/win32/include/xmlversion.h file defines LIBXML_ICU_ENABLED. This causes encoding.h to include unicode/ucnv.h which seems unavailable on Windows. So either I #ifdef around the third party library source but that would be a bad hack. We use ICU. It's in third_party/icu38. You can use the build/using_icu.vsprops to set VS to search in these directories for includes. Brett --~--~-~--~~~---~--~~ 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: NSS and NSPR
OK, I'm planning to go with the borrowed 32-bit Ubuntu libs for nss, nspr, and sqlite. These libs won't go in our source tree, but will magically appear from somewhere at packaging time (in reality, probably just pulled from the build host, since that's already configured properly). This will add a bit more than 1MB to the download, at least the first time. When installed, they'll live in the chromium directory and be invoked through a chromium wrapper script with LD_LIBRARY_PATH. This is subject to change with something more elegant/robust, but that should be good enough to start dogfooding. Please let me know if there are any objections. Michael On Thu, Feb 26, 2009 at 10:54 AM, Michael Moss mm...@chromium.org wrote: On Thu, Feb 26, 2009 at 10:40 AM, Dean McNamee de...@chromium.org wrote: We don't need to stick the .so's in /usr/lib32 then do we? We can stick them in our own directory if that's the concern. I don't understand have this relates to building our own .so's or reusing someone elses, since either way you have the problem of us shipping one, and someone might already have one. I think we're in agreement here, but I was more just arguing against the separate package dependency. If it's installing to our directory, it might as well not be a separate package. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
