315890 - Move extensions/xmlextras somewhere

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Benjamin Smedberg]

I need to move extensions/xmlextras "somewhere in tier 9" so that it can be incorporated into libxul. There are three options:

1) By far the easiest thing for me to do is move the code exactly as is to content/xmlextras and have it continue building it's own XPCOM component (it would not be part of the gklayout.dll component).

2) Slightly harder, but within my immediate capabilities, is to move extensions/xmlextras to content/xmlextras and move it into the layout module. This is slightly harder because I think I need to preserve some kind of --disable-xmlextras configure option.

3) Some have suggested moving the individual pieces of xmlextras into the "correct" locations in the file hierarchy... I don't even know what these are, and I don't think I have time to do this. So unless somebody steps up and can get something done in the next week or so, I'd like to go with option 1 or 2.

Comment 1

[Doron Rosenberg (IBM)]

Does anyone actually use --disable-xmlextras?  I believeminimo builds with xmlextras these days.

Would we save much in terms of diskspace by using option 2 (I assume it would compile then into gklayout)?

Comment 2

[Benjamin Smedberg]

Thunderbird currently does not build xmlextras.

The disk space diff between 1) and 2) would probably be minimal.

Comment 3

[Darin Fisher]

Why does xmlextras need to physically move in the tree?  Why not just fix the build machinery to deal with stuff in mozilla/extensions?

Comment 4

[Benjamin Smedberg]

The build machinery for mozilla/extensions is poor, and I'm trying to move most things that are not actually extensions out of that directory.

Comment 5

[Darin Fisher]

> The build machinery for mozilla/extensions is poor, and I'm trying to move most
> things that are not actually extensions out of that directory.

We could fix the build machinery for mozilla/extensions, no?  Or, rather... couldn't we work around it by adding extensions/xmlextras to one of the earlier build tiers and then remove it from MOZ_EXTENSIONS_ALL (or whatever the configure.in variable is)?

At any rate, it would seem that option #3 is probably best for xmlextras, so I was thinking that it might be easier to unblock your work by hacking the build machinery instead of trying to figure out how best to refactor xmlextras into the rest of the tree.  Just my 2 cents...

Comment 6

[Benjamin Smedberg]

I'm wrong about tbird, it does enable xmlextras, because extension manager and update depend on XMLHttpRequest.

Comment 7

[Benjamin Smedberg]

Attachment: darin's expedient solution

This is darin's expedient solution, to keep the files in extensions/xmlextras for the time being and just build them from a different tier.

Comment 8

[Doron Rosenberg (IBM)]

Comment on attachment 203429 [details] [diff] [review]
darin's expedient solution

Did you mean darin?

Comment 9

[Doron Rosenberg (IBM)]

Comment on attachment 203429 [details] [diff] [review]
darin's expedient solution

jst is really the module owner.

Comment 10

[Johnny Stenback (:jst)]

Comment on attachment 203429 [details] [diff] [review]
darin's expedient solution

r+sr=jst

Comment 11

[Benjamin Smedberg]

Fixed on trunk.

Comment 12

[Mike Shaver (:shaver emeritus)]

Comment on attachment 203429 [details] [diff] [review]
darin's expedient solution

We need this on the 1.8 branch as well.

Comment 13

[Mike Shaver (:shaver emeritus)]

(I tried to apply that patch on the branch, but wasn't able to trivially resolve the rejections, so I just forced xmlextras to build and moved on with my places-testing life.)