202450 - Improve NSBrowserView framework

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: Mac, defect)

Description

[Conrad Carlen (not reading bugmail)]

It needs to be made to be generic and reusable by any cocoa embedding app.
The 1st specific problem is its use of CHBrowserService. It inits Gecko
implicitly which is bad because different apps will want to do different things
at that level - WRT profiles, component overriding, etc.

Oh, and I'd really love to strike the CH from all filenames in this thing ;-)

Comment 1

[Mike Pinkerton (not reading bugmail)]

the reason we chose CH was so as to avoid conflict with the embedding
application if it didn't use the framework directly. the thought was that 'ns'
was too close to 'NS' and would cause more confusion.

Comment 2

[Simon Fraser [no longer active]]

NSBrowserView is too close to NSBrowser, and various other Cocoa classes. I
think we need a distinct prefix.

I agree that it needs to be more generic.

Comment 3

[Michael Buckland]

Discussed in edt bug triage.  Plussing.

Comment 4

[Brian Ryner (not reading)]

Just brain dumping some stuff Conrad and I have talked about related to making a
generic Gecko embedding framework:

- It would be great if the framework could load Gecko fully prebound.  My
initial tests show that SeaMonkey startup time gets 25% faster if you do that. 
I did that by using a mozcomps meta-component build, making the metacomponent be
a dylib instead of a bundle, linking mozilla-bin against it directly, and using
the static component loader to register its components.

- You should be able to just say "-framework Gecko" (or whatever we end up
calling the framework) when linking your application and not have to give any
other gecko-related libraries unless you use functionality that goes beyond what
the Cocoa wrapper provides.  If we wanted, we could make it so you get all the
XPCOM symbols for free too, by using the linker -sub_library flag.

- Everything related to Gecko should be able to run from inside the framework
directory; nothing should be required to be in the application bundle.

- We could include our frozen embedding interfaces in the framework's Headers
directory.

Comment 5

[Conrad Carlen (not reading bugmail)]

Attachment: Gecko.framework

This builds a completely packaged Gecko framework, containing everything in a
Gecko distribution - all components, resources, headers, etc. The headers are
simply everything in dist/sdk/ flattened into 1 directory.

Other highlights:
* It uses bryner's in-progress work to link the framework lib with the prebound
meta-component which is built as a dynamic lib, not a component.
* It merges all .xpt files into one to avoid explicit inclusion of tons of
files in the project.
* It does not require a make in embed/config first. Since a framework is itself
an encapsulation, no need to do that after an initial encapsulation. It does,
though, need to make the chrome using the makefile in embed/config. It does
that using a legacy makefile target on which the main target depends.
* It provides some glue which inits faster that NS_InitEmbedding and offers the
convenience of setting up directory service providers for the app and for a
single profile. The client app just passes a simple string.

Comment 6

[Conrad Carlen (not reading bugmail)]

Attachment: cocoaEmbed which uses it

Notice that there's almost nothing in this project now - no Gecko files, no
Gecko include paths. The only problem is that there are numerous dylib_file
flags which need to be passed to the linker. Trying to find a way around that.

Comment 7

[Conrad Carlen (not reading bugmail)]

New plan is to build this in embedding/wrappers so that it's not tied just to
cocoa. Instead, there will be two targets in the framework project and the
Makefile which calls pbxbuild will use the current toolkit to select which
target to build.

Comment 8

[Conrad Carlen (not reading bugmail)]

Attachment: + prebinding, install_name configure fun

New patch - based on bryner's componentlib work. This patch also adds some
features to build configurability:

1. --enable-framework - builds the current framework, which implicitly turns on
prebinding
2. --enable-dylib-install-name-path - needed depending on where you want to
install the framework.

Other stuff:
* Prebinding support has been improved in that you don't have to build from the
top level in order for it to take affect on c-sdk and nspr - it's incorporated
into their config file and mozilla's propagates those options down.
* Because the install-name for dylibs is now configurable, the prebinding
address table has to be generated dynamically.

Comment 9

[Conrad Carlen (not reading bugmail)]

Attachment: correction to attachment 125587

The change to security/manager/Makefile.in in attachment 125587 [details] [diff] [review] wasn't right.
It was using a hardwired value for -install_name if MOZ_FRAMEWORK, rather then
picking up the definition from config/autoconf.mk

Comment 10

[Conrad Carlen (not reading bugmail)]

Wan-Teh, can you r= the build changes in nspr and security? Bryner did the
security changes and provided a lot of this.
dmose, can you r= the changes to directory/c-sdk? They're the same as what was
done in nspr.

Here's what is does:

(1) Makes a dylib's install_name configurable. .dylibs with which the app links,
either directly or indirectly, need to be able to be located in some directory
other than the executable. Using only @executable_path/ prevents us from
building these libraries into a framework. Even if not building a framework,
some apps may wish to put these .dylibs in some other place and this allows for
that. The patch makes the install_name configurable but default to its current
value.

(2) Makes prebinding configurable in sub build systems, but propagates settings
down from mozilla. Currently, prebinding works by exporting variables from
mozilla/config/rules.mk. Problem is, it only works in these sub build systems if
you do a top-level build from mozilla. This allows you to, one you've done an
initial top-level configure, to cd into nspr, etc., make, and the right thing
happens with prebinding.   

Comment 11

[Wan-Teh Chang]

Comment on attachment 125587 [details] [diff] [review]
+ prebinding, install_name configure fun

1. I can't take the following change to nsprpub/config/config.mk
because NSPR should not contain the pathname of a file outside
NSPR (prebind-address-table).

>+ifeq ($(OS_ARCH),Darwin)
>+ifdef USE_PREBINDING
>+export LD_PREBIND=1
>+export LD_SEG_ADDR_TABLE=$(shell cd $(DIST)/../; pwd)/config/prebind-address-table
>+endif
>+endif

Could you please come up with a different solution?

2. In security/manager/Makefile.in, could you set INSTALL_NAME_PATH
as part of DEFAULT_GMAKE_FLAGS, instead of as an environment
variable?

Comment 12

[Conrad Carlen (not reading bugmail)]

> NSPR should not contain the pathname of a file outside NSPR

Having the prebind address table be shared by everything in the build is important.
Looking at the contents of this file, 
http://lxr.mozilla.org/seamonkey/source/config/prebind-address-table, you can
see that de-centralizing it would make for a big maintainence problem. Clearly,
a prebind address table needs to be shared by everything in the build - we just
need to find a way that's acceptable.

What if this code is only defined for MOZILLA_CLIENT?
What if it checks for the existence of the file first?

>+export LD_PREBIND=1
>+export LD_SEG_ADDR_TABLE=$(shell cd $(DIST)/../; pwd)/config/prebind-address-table


> could you set INSTALL_NAME_PATH as part of DEFAULT_GMAKE_FLAGS

If the value of DEFAULT_GMAKE_FLAGS is available to all the sub makefiles in
security, that shouldn't be a problem.

Comment 13

[Wan-Teh Chang]

I am sure that there are ways to avoid adding the pathname
of Mozilla client's prebind address table to NSPR.  One
simple solution is to have NSPR's --enable-prebinding configure
option take that as an argument.  I also suspect that it is
possible to prebind dynamic shared libraries as a
postprocessing step (i.e., after they are built).  If so,
you could prebind NSPR's dynamic shared libraries in a
Mozilla makefile, similar to the way Mozilla strips NSPR's
shared libraries on Unix
(http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/Makefile.in#212)
and rebases NSPR's DLLs on Windows
(http://lxr.mozilla.org/seamonkey/source/Makefile.in#409).
I prefer prebinding NSPR's dynamic shared libraries as a
postprocessing step, if there is a way to do that.

Comment 14

[Brian Ryner (not reading)]

Conrad: it wouldn't be impossible for nspr to have its own prebind address
table, as long as we noted what range it was using for the rest of the Mozilla
build.

wtc: prebinding has to be done at link time.

Comment 15

[Conrad Carlen (not reading bugmail)]

> it wouldn't be impossible for nspr to have its own prebind address
table

Yeah, though it would be a maintainence problem - especially if the same was
done for c-sdk and security. I think we should be consistent.

wtc: I'll go with your suggestion of having NSPR's --enable-prebinding configure
option take the path of the prebind table as an argument.

Comment 16

[Benjamin Smedberg]

Mass change of bugs in the Embedding: Mac component in preparation for archiving it. I don't believe any of these are useful any more, as we don't have a mac embedding API. If they are relevant, they should be moved to an alternate component.