Hi all,
Recently we have a few bugs regarding the variety of features of
different devices/platforms. See bug 920551 [1] and bug 939056 [2].
The problem is: shall we allow --disable-foo in per device configuration?
Right now we have a file named 'default-gecko-config' inside gonk-misc/.
The file contains 23 default |ac_add_options ...| lines and several of
them are further controlled by environment variables exported in
'.config' and/or '.userconfig'.
Besides, there is also another way to inject such compile time options.
The 'Android.mk' file in same gonk-misk/ directory suggests one may
assign "GECKO_CONFIGURE_ARGS" in any other "Android.mk" files, and the
value will be passed as "CONFIGURE_ARGS" env variable to Gecko during
the configure stage. The best home for this variable is per device
'BoardConfig.mk' for sure.
So back to the original problem: shall we allow --disable-foo in per
device configuration? That is: shall we allow assigning
"GECKO_CONFIGURE_ARGS" in per device 'BoardConfig.mk'?
I would say YES. My 2 cents:
1) Code size.
Back to bug 864485 [3], migrating Telephony IPC from frame messaging to
IPDL, Telephony DOM code was then built on ALL platforms just like what
we have for MobileMessage. By ALL, I mean it's compiled even on
Windows. Then I got a regression mail saying the built binary size grew
1% after that patch on platforms didn't have WebTelephony before.
Taking current /system/lib/libxul.so for example, 1% means 230KB. I
heard there is some kind of delayed loading tech in use, but this still
comes to my mind first when we were to built-in some dead code in final
executables.
2) Runtime detection may lead to a certain problem.
The two bugs, 920551 and 939056, are for enabling/disabling a certain
B2G feature(s) on different devices. These features come with DOM APIs
for sure. For now we're to hide APIs from user content when it's not
available. Runtime detection is suggested but it takes time. It
follows the first call to retrieve the availability of such feature
should only be made after we're fully confident/determined there is no
such feature on that device. For example, FTU need to know whether does
the device implement RIL APIs or not before it's to display a menu item
for "Import SIM contacts". Such calls have to be delayed after runtime
detection is done, and again these detections take some time. Why not
just skip these detections on devices that have no such feature at all?
3) How and why
Till now, all devices have their own Gecko binaries. They're built
directly from the source code and each of them is basically different
from each other. No any devices share Gecko binaries at the time at
all. Some devices have even additional patches to Gecko applied, and
some replaces built-in components with their own. Mozilla just can't
stop device makers from compiling Gecko by their own. And we just
shouldn't do so, either. The thing we should only care is to provide
unified Web API interfaces to users, not binary monopoly to device makers.
So, what would you say?
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=920551
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=939056
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=864485
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
