571115 - Figure out what to do about the removal of the frozen embedding API

Status: RESOLVED WONTFIX

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The frozen embedding API (NS_InitEmbedding) was just suddenly removed in bug 569948, which returns us to a position of being unable to build on trunk.

It's unclear what to do right now.

1) bsmedberg's initial suggestion was to just copy the removed code into Camino (bug 569948 comment 13), but that seems like it's not going to be useful if we won't be able to register/load components soon (bug 569948 comment 3) anyway.  It's possible this would work as a short-term fix, depending on how long it is until bug 568691 lands.

2) Switch to XRE_InitEmbedding, which apparently obsoleted NS_InitEmbedding.  I don't know anything about this, except that it lives in toolkit/xre, which means it's part of the xulapp module, which means it gets linked in with all of the XUL app stuff we don't want/need (broken toolkit AppleEvent handling, broken toolkit Mac command-line handling, toolkit application and startup code, toolkit crashreporter, toolkit Growl…).  I don't know if there are internal dependencies between nsEmbedFunctions.cpp and the rest of toolkit/xre, or if we could just build that and link it ourselves.

3) Something else?

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Theoretical implementation of 1

Er, Nick's on his ride this week, so he won't be able to offer any useful advice for a while :(

However, this is (I think) and implementation of 1 as a temporary band-aid.  I haven't rebuilt my entire tree with it, but I did a cursory rebuild of camino/ and it didn't fail.  This should apply on top of the latest patch in bug 569782 (you may have to apply the Camino Makefile hunk yourself, since it has my striptease comment-out that's not in the "Packaging changes" patch).

Since the Core changes didn't remove building the xpt, and since we don't have to support Win32 or OS/2, it's a stripped-down Makefile and a flattened directory structure (more cleanup possible in the cpp).

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Implementation of 1, v1.1

philippe still failed to build with the previous iteration of this temp hack; ld failed to find our new libembed_base_s.a.  Apparently Xcode 3.2 really needs those LIBRARY_SEARCH_PATHS and Xcode 3.1 does not :P

This patch fixes the library search paths in the project (at least until bug 570373 is fixed), and applies on top of "Fix, 1.3c" from bug 569782.

Comment 3

[Stuart Morgan]

Inability to build against Gecko 2 (FKA 1.9.3) is permanent.