OTA size modular builds?

[Naoki Hirata]

There was a 15 MB increase within the last several months.

Part of the size change has to do with gecko support for new gaia features.

Even if the app is not added to gaia, the gecko portion will still have the code.

I was wondering would it be possible to make the gecko portion be just as modular?

ie a way to drop the compile of the gecko side if the vendor doesn't want to include a feature?

[Tim Guan-tin Chien]

Do you have bug # as examples?

Can we not compile these script with more build flags?

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>

[Thomas Zimmermann]

cc'ing dev-fxos, as dev-{b2g,gaia} are deprecated

Hi

Am 13.09.2015 um 07:15 schrieb Naoki Hirata:
> There was a 15 MB increase within the last several months.
> Part of the size change has to do with gecko support for new gaia
> features.
>
> Even if the app is not added to gaia, the gecko portion will still
> have the code.
>
> I was wondering would it be possible to make the gecko portion be just
> as modular?
> ie a way to drop the compile of the gecko side if the vendor doesn't
> want to include a feature?

I generally dislike the idea of a modular Gecko builds. We sometimes
have problems because RIL is optional. Testing all the different
combinations will become a QA nightmare as the number of individual
modules increases. If Gecko's size is a problem, we should first try to
shared more code between Gecko features. I feel that there's still
potential.

If only the size of the OTA is a problem, we might be able to send out a
binary diff of the changes, which is applied to the existing files on
the device. Creating the diff file would require patch tools that
understand ELF binaries.

Best regards
Thomas

>
>
>
>
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

[Naoki Hirata]

Thanks Thomas for the feedback.  You are right, testing will be a nightmare.  At the same time, reducing space is necessary if we're to fit on the flame device for OTA. 

Tim, I found a regression range :

12 MB change; 2.28 MB, patch just for PocketSphinx etc. the voice engine for Vaani.

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e5ee2c56963c&tochange=0920f2325a6d

There is a 3 MB difference comes between this change set: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ba43a48d3c52&tochange=08015770c9d6

Together with both these ranges that's a 15 MB difference.

Regards,

Naoki