[jafd]

I mean, if there is system-supplied XULRunner, system-supplied GStreamer, system-supplied everything. Whilst not as critical for alternative platform users, this is crucial and time/space-saving for Linux and BSD users.

I'd like to know if this is at all planned.

[Manko10]

Welcome!

System GStreamer is definitely planned, although I don't know if it isn't already implemented.
System XULRunner, however (probably the biggest time saver) will not be possible, at least not in the near future. Too many modifications have been made to it.

[jafd]

I reckon there are two reasons to modify an existing platform: the first is when it actually is missing something (in which case there is, surprisingly, XPCOM, which allows throwing in arbitrary components written in almost anything), the second is when one cannot figure out how to do it natively (which is what I expect from a generic C++ engineer with no incentive to deepen the knowledge of XUL/JS/XPCOM and a deadline looming).

Oh and by the way, there is XULRunner 2.0 around, which is my point of interest currently. I have Firefox as a XULRunner app, and would like NGale to be the same.

---

My real point is that there should be at least a way to force the use of a particular SDK (as of Songbird trunk, I cannot just symlink xulrunner/ to it, it will die if that's a symlink, for a reason I better not ask). Then, there can be a milestone in Trac and a ticket for all individual failures encountered when building and eventually running the build.

That would at least help determine the lowest hanging fruits to start with.

[pythonian4000]

Nightingale builds by default now using system GStreamer, and stevo has been doing an excellent job of reducing the number of custom libraries that we depend on. Unfortunately, Xulrunner is, as mentioned above, too heavily modified as it is. Songbird trunk currently uses XULRunner 1.9.2 (the version we are starting at is I believe 1.8 (or at least something earlier)) but that also is modified.

[jafd]

Has anyone run a diff between xulrunners to see what sorts of changes these were?

My C++-fu is sub par, but there's a suggestion floating around me that some things can be refactored into XPCOM components.