Adding third party code/libraries to chromium

[Satish Sampath]

Hi,

I'm looking to use the open source Speex codec in some chromium code. Speex source is available either via GIT or as specific version downloads from http://www.speex.org/downloads/ . I notice that we have trunk/deps/third_party (which perhaps gets pulled via 'gclient sync' and the DEPS file?) and trunk/src/third_party (which looks like a snapshot of the stable version from the third party repository). Which one of these is appropriate for libraries such as speex?

--

Cheers

Satish

[Marc-Antoine Ruel]

If it's not to be used on all platforms, put it trunk/deps/third_party and fetch with deps_os.

If it's to be used on all platform, you can put it in trunk/src/third_party.

Don't forget README.chromium and LICENSE and trim the sources if relevant.

M-A

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Evan Martin]

Please use the first one.

The difference is that the latter option adds your library to the mass
of files that are checked out when you check out Chrome, which means
operations like "svn diff" from the project root will have to look
through your library's files for diffs as well, slowing down most
operations.

Please run tools/licenses.py before checking in your initial
changelist to verify you got the licensing information correct.

[Paweł Hajdan, Jr.]

By the way, make sure to get security review of the third party code. Codecs are especially risky.

--

[Adam Langley]

On Fri, Aug 13, 2010 at 1:25 PM, Evan Martin <ev...@chromium.org> wrote:
> Please run tools/licenses.py before checking in your initial
> changelist to verify you got the licensing information correct.

Please also consider that this is about 100K of code bloat which needs
to be justified. Chrome is still supposed to be a browser after all.

It's also a large amount of code which is getting put on the security
frontline. Codecs are typically troublesome from a security point of
view and this should require someone from our overworked security team
to audit/fuzz before it lands without a flag.

Also, Linux distributions will want the ability to link against the
system version of this library. (See third_party/zlib for example.)

AGL

[Jeremy Orlow]

The code bloat is a concern.  Satish, do you have any numbers on what a Chromium release build looks like with and without it?  Is it possible to trim things down some?

But security is probably less so.  It'll only be used for communicating to Google's servers (to do the speech processing).  So while it's good to try and make it security, it won't be the same sort of attack surface that something like an <audio> tag codec would be.

J

[Satish Sampath]

> If it's to be used on all platform, you can put it in trunk/src/third_party.

It is to be used on all platforms.

> Please use the first one.

Hmmm, this conflicts with what M-A mentioned above.. still wondering which directory is recommended..

--

Cheers

Satish

[Satish Sampath]

I haven't started using speex yet in chromium so don't have chromium specific details on the binary size. However the command line encoder and decoder which come along with the code are about 80kb combined (release build, windows).

--

Cheers

Satish

[Marc-Antoine Ruel]

Le 13 août 2010 13:57, Satish Sampath <sat...@chromium.org> a écrit :

I haven't started using speex yet in chromium so don't have chromium specific details on the binary size. However the command line encoder and decoder which come along with the code are about 80kb combined (release build, windows).

Don't check-in binaries in src/ so you have your answer.

[Satish Sampath]

I haven't started using speex yet in chromium so don't have chromium specific details on the binary size. However the command line encoder and decoder which come along with the code are about 80kb combined (release build, windows).

Don't check-in binaries in src/ so you have your answer

I wasn't going to check in binaries :) and the above information was just for the size comparison with the binaries generated on my machine. So I'm still wondering where the source would go..

--

Cheers

Satish

[Evan Martin]

On Fri, Aug 13, 2010 at 1:04 PM, Satish Sampath <sat...@chromium.org> wrote:
>> Don't check-in binaries in src/ so you have your answer
>
> I wasn't going to check in binaries :) and the above information was just
> for the size comparison with the binaries generated on my machine. So I'm
> still wondering where the source would go..

I think my proposal was better. What do you say, Marc-Antoine? :)

[Marc-Antoine Ruel]

I don't mind. With gclient's parallel checkout that was checked-in 5 minutes ago, it's not big deal to have multiple repos.

Try gclient sync --jobs 32 at home to see.

M-A