On Thu, Apr 23, 2009 at 22:40, Robert Dailey wrote:
> Filed a feature request:
> http://code.google.com/p/chromium/issues/detail?id=10955
>
My response to the bug (closed WontFix):
mini_installer can never have a UI. It needs to remain silent for automatic
updates.
In some cases it may get laun
hi there,
thanks for working on getting the shared lib of libraries! I was
pointed to this work by Evan Martin as well and he pointed me to this
(http://codereview.chromium.org/88058). However I am having some
difficulty getting it to build and it errors out while building
libxml.
==
Looks like it's missing -ldl, but I haven't looked closely.
On Fri, Apr 24, 2009 at 12:57 PM, nshah wrote:
>
> hi there,
>
> thanks for working on getting the shared lib of libraries! I was
> pointed to this work by Evan Martin as well and he pointed me to this
> (http://codereview.chromium.org/
This group is very impressive, always so quick in reply!
Thanks for quick reply!
I did hammer --verbose and here is the command if that helps:
cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/base
&& ../chrome/tools/build/linux/version.sh
file_version_info_linux.h.version /home/d
The obvious fix would be to add -ldl, but I don't see why libxml
should be using it...
>From a quick peek at the code, I saw xmlmodules.c using dlerror / etc
for dynamic module support. Since libxml is running sandboxed, do we
really want dynamic module support?
In specific, it seems like we ha
could you please tell me what files I have to modify to add -ldl ?
When I do command line with -ldl option it goes without error but the
automated build using hammer is obviously regenerating some files that
still miss -ldl option.
Thanks,
On Apr 24, 8:26 am, Dean McNamee wrote:
> The obvious
Hi
At some point I had used -ldl in the xml gyp file but then I dropped
that when I purely
targeted chrome and not any of the other targets ... in fact I haven't
even tried building
the other targets for a while so it's quite possible that they won't
build as shared targets.
Try
hammer app
and s
Hmmm ... actually it seems as if -ldl is present in
third_party/libxml/libxml.gyp ... so take a look if it's there for you
and run gclient sync if it isn't. Try running gclient runhooks --force
if none of the other things work. Perhaps your scons files have not
been updated properly.
--Craig
On
actully I saw it there but then I was not sure if it needs another
condition block for shared_library but before asking you again I
wanted to try to build chrome (hammer app) and see if that works as
you suggested.
Thanks!
Nidhi
On Apr 24, 9:16 am, Craig Schlenter wrote:
> Hmmm ... actually it
On Fri, Apr 24, 2009 at 2:40 AM, Mark Larson (Google) wrote:
>
>
> On Thu, Apr 23, 2009 at 22:40, Robert Dailey wrote:
>
>> Filed a feature request:
>> http://code.google.com/p/chromium/issues/detail?id=10955
>>
>
> My response to the bug (closed WontFix):
>
> mini_installer can never have a UI.
ok , so building chrome terminated with this error.
scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/lib/libglue.so] Source file: /home/dev/
ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/
WebKit/WebCore/Configurations/Version.xcconfig
Actually all the targets work ... Steven fixed them all and I just
hadn't realised that so the hammer app thing and my earlier rambling
is ignorable. I see from your other mail that you are using the
tarball though so I'd recommend trying to sync up with the current svn
trunk. It should al
Just to follow up explicitly to what Craig said, you should do
something like the following, and make sure there are no errors:
# Clobber
rm -rf sconsbuild
# Make sure everything is up to date
gclient sync --force
# Make sure the scons files were regenerated from the gyp files
gclient runhooks --
woot!
On Thu, Apr 23, 2009 at 11:02 PM, Brett Wilson wrote:
>
> I just moved the remaining methods from WebContents to TabContents. I
> kept the methods and data members the same, just merged the classes,
> so it should be easy to find what you're looking for (or to resolve
> conflicts if you ha
Congrts, Brett!
-- Erg.
On Fri, Apr 24, 2009 at 9:15 AM, Erik Kay wrote:
>
> woot!
>
> On Thu, Apr 23, 2009 at 11:02 PM, Brett Wilson wrote:
>>
>> I just moved the remaining methods from WebContents to TabContents. I
>> kept the methods and data members the same, just merged the classes,
>> so
There are now different platform-dependent ways to ensure that only
one instance of Chrome is running, and to get its pid.
I think that there is a way of accomplishing both goals in a
cross-platform way, reusing existing IPC system.
I'll try to explain how IMO things are now, and why this might be
Currently there are different implementations of ProcessSingleton and
ChromeBrowserProcessId() on Windows, Linux and Mac. Most of them are
quite hacky, so there should be a better way. I think current IPC
system with slight modifications can replace them all.
Now:
1. Windows
Hidden top-level wind
On Thu, Apr 23, 2009 at 1:35 PM, Nikita Ofitserov wrote:
> I suggest:
> Don't try to get pid dynamically, but create on startup in datadir
> file 'ChromePid' or something like that with pid.
Creating files during startup would slow startup too much. Chrome crashing
would leave a stale PID file
Is it possible to use views without an instance of BrowserProcess or
are they very tightly coupled?
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.
At present views has some dependencies on some other parts of the
browser infrastructure but I plan to sever a lot of this in the coming
month or two.
-Ben
On Fri, Apr 24, 2009 at 7:36 PM, Book'em Dano wrote:
>
> Is it possible to use views without an instance of BrowserProcess or
> are they ve
Okay, thanks Ben
On Apr 24, 7:38 pm, "Ben Goodger (Google)" wrote:
> At present views has some dependencies on some other parts of the
> browser infrastructure but I plan to sever a lot of this in the coming
> month or two.
>
> -Ben
>
> On Fri, Apr 24, 2009 at 7:36 PM, Book'em Dano wrote:
>
> >
I have noticed some of these creep in in the past couple of weeks.
DO NOT DO IT.
Or I will hunt you down.
I am trying to extract views from chrome/ and every time you do this,
it adds spaghetti to the plate and makes my life harder.
-Ben
--~--~-~--~~~---~--~~
C
Is it possible to enforce these rules with code rather than capital letters?
I don't think I've made this particular error, but it's something I
could see myself doing. From their names, "chrome/common" seems like a
reasonable thing to include from "chrome/views".
Just a thought. Don't we have s
On Fri, Apr 24, 2009 at 10:10 PM, Aaron Boodman wrote:
>
> Is it possible to enforce these rules with code rather than capital letters?
>
> I don't think I've made this particular error, but it's something I
> could see myself doing. From their names, "chrome/common" seems like a
> reasonable thi
Sadly, chrome/common sounds generic enough that it's become a place to
stash files. I'm not blameless - for some reason I put Animation
there, when it clearly belongs in views/.
Common's purpose is for files shared between two or more subdirs of
chrome where those subdirs are peers on the depende
I want to extract views/ from chrome/ so it can be used by other projects.
Before this can be done, views' dependencies on other dirs need to be
tidied up. Right now it depends on:
base/
build/build_config.h
chrome/app/chrome_dll_resource.h
chrome/common/clipboard_service.h
chrome/common/drag_dr
26 matches
Mail list logo
