Closed Bug 794698 Opened 12 years ago Closed 7 years ago

move nsGIOProtocolHandler.cpp out of extensions

Categories

(Firefox Build System :: General, defect)

All
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1344038

People

(Reporter: karlt, Unassigned)

Details

Extensions are not a liked configuration mechanism (Bug 713802 comment 29).

nsGIOProtocolHandler.cpp need not be an extension.
It can even be compiled into libxul, because GIO will already be required by the icon image decoder.  GIO is part of the GLib version Firefox require's now.

Ideally we'd still keep a build config option, perhaps --enable-gio-protocol-handler, because this adds protocols not normally handled by web browsers.

Not sure where the code should move to.  network/system/ perhaps.
There is already quite a bit of gio code in libmozgnome.so, and that will no longer depend on GNOME when GnomeVFS is dropped, so perhaps it can move to toolkit/system.  (That whole component could be built into libxul.)
(In reply to Karl Tomlinson (:karlt) from comment #0)
> (That whole component could be built into libxul.)

Only when gnomevfs support is disabled. Which leads to another question: at what point can we consider removing gnomevfs support code.
GnomeVFS support is disabled in Firefox and I assume it can be disabled on comm-central too, now that Thunderbird builds are on CentOS 6.

There isn't much reason for keeping GnomeVFS support around.  The only benefits of having it still there are it makes it easier to re-enable in case we discover some unforeseen reason to do so, or perhaps to make it easier for RedHat to support EL 5.8.

Neither of those are really reasons not to build in libmozgnome, assuming build changes can be reverted easily if necessary.  RedHat will have their own builds for EL 5.8, so they can sort out necessary dependencies.

I expect the GnomeVFS code can be removed altogether once 18 is shipped with GIO, or perhaps before that.
(In reply to Karl Tomlinson (:karlt) from comment #2)
> Neither of those are really reasons not to build in libmozgnome, assuming
> build changes can be reverted easily if necessary.

We can ifdef the component being built separately, too.
Fixed in bug 1344038.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.