Hello Chromium Devs, The O3D team is working on getting O3D integrated into the Chromium build, and we're close to being able to complete our first step towards integration: To build the O3D plugin as part of the Chromium code base, and link it into Chromium DLL. It will still be a "plugin", but will be added to the internal plugins list so that its entry points are found in the Chromium DLL, instead of loading a separate plugin DLL. This is a small step, and makes little practical difference except that 1) it will be bundled with Chromium, and 2) it opens the door to start integrating more fully.
To achieve this first step, we have converted the O3D plugin to build using GYP, and have migrated to using all of the third_party libraries that we have in common at the same revision levels as Chromium is using.
The next thing to do is to change Chromium's DEPS file to include the few remaining necessary dependencies that O3D uses and Chromium does not.
These are: A vector math library (vectormath), Nixysa: an NPAPI IDL generator, gflags (the python parts, for nixysa), and native client (for the nacl imc libraries).
In addition, I'll be making the Windows build of Chromium be dependent upon building O3D as part of the build process.
This is really just a "heads up!" announcement to prompt heated discussions about the ensuing calamities that this will cause, so please feel free to comment.
On Tue, Jul 21, 2009 at 4:30 PM, Greg Spencer <gspen...@google.com> wrote:
> Hello Chromium Devs,
> The O3D team is working on getting O3D integrated into the Chromium build,
> and we're close to being able to complete our first step towards
> integration: To build the O3D plugin as part of the Chromium code base, and
> link it into Chromium DLL. It will still be a "plugin", but will be added
> to the internal plugins list so that its entry points are found in the
> Chromium DLL, instead of loading a separate plugin DLL. This is a small
> step, and makes little practical difference except that 1) it will be
> bundled with Chromium, and 2) it opens the door to start integrating more
> fully.
> To achieve this first step, we have converted the O3D plugin to build using
> GYP, and have migrated to using all of the third_party libraries that we
> have in common at the same revision levels as Chromium is using.
> The next thing to do is to change Chromium's DEPS file to include the few
> remaining necessary dependencies that O3D uses and Chromium does not.
> These are: A vector math library (vectormath), Nixysa: an NPAPI IDL
> generator, gflags (the python parts, for nixysa), and native client (for the
> nacl imc libraries).
> In addition, I'll be making the Windows build of Chromium be dependent upon
> building O3D as part of the build process.
> This is really just a "heads up!" announcement to prompt heated discussions
> about the ensuing calamities that this will cause, so please feel free to
> comment.
On Tue, Jul 21, 2009 at 4:30 PM, Greg Spencer <gspen...@google.com> wrote:
> Hello Chromium Devs,
> The O3D team is working on getting O3D integrated into the Chromium build,
> and we're close to being able to complete our first step towards
> integration: To build the O3D plugin as part of the Chromium code base, and
> link it into Chromium DLL. It will still be a "plugin", but will be added
> to the internal plugins list so that its entry points are found in the
> Chromium DLL, instead of loading a separate plugin DLL. This is a small
> step, and makes little practical difference except that 1) it will be
> bundled with Chromium, and 2) it opens the door to start integrating more
> fully.
> To achieve this first step, we have converted the O3D plugin to build using
> GYP, and have migrated to using all of the third_party libraries that we
> have in common at the same revision levels as Chromium is using.
> The next thing to do is to change Chromium's DEPS file to include the few
> remaining necessary dependencies that O3D uses and Chromium does not.
> These are: A vector math library (vectormath), Nixysa: an NPAPI IDL
> generator, gflags (the python parts, for nixysa), and native client (for the
> nacl imc libraries).
Overall it looks good to me, with some comments/questions:
> # 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.
And if we really can't, then.... this path does not exist on head for this
repo. Any change we can sync to a later revision so we don't have to change
the path later on?
> In addition, I'll be making the Windows build of Chromium be dependent upon
> building O3D as part of the build process.
> This is really just a "heads up!" announcement to prompt heated discussions
> about the ensuing calamities that this will cause, so please feel free to
> comment.
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.
> 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.
On Wed, Jul 22, 2009 at 9:51 PM, Nicolas Sylvain<nsylv...@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.
|
