Closed
Bug 202450
Opened 21 years ago
Closed 8 years ago
Improve NSBrowserView framework
Categories
(Core Graveyard :: Embedding: Mac, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: ccarlen, Assigned: ccarlen)
References
Details
(Keywords: topembed+, Whiteboard: edt_c3,edt_d3)
Attachments
(2 files, 2 obsolete files)
124.91 KB,
patch
|
Details | Diff | Splinter Review | |
726 bytes,
patch
|
Details | Diff | Splinter Review |
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•21 years ago
|
||
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.
Keywords: topembed
Comment 2•21 years ago
|
||
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•21 years ago
|
||
Discussed in edt bug triage. Plussing.
Comment 4•21 years ago
|
||
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.
Assignee | ||
Comment 5•21 years ago
|
||
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.
Assignee | ||
Comment 6•21 years ago
|
||
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.
Assignee | ||
Comment 7•21 years ago
|
||
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.
Assignee | ||
Comment 8•21 years ago
|
||
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.
Attachment #124090 -
Attachment is obsolete: true
Attachment #124091 -
Attachment is obsolete: true
Assignee | ||
Comment 9•21 years ago
|
||
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
Assignee | ||
Comment 10•21 years ago
|
||
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•21 years ago
|
||
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?
Assignee | ||
Comment 12•21 years ago
|
||
> 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•21 years ago
|
||
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•21 years ago
|
||
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.
Assignee | ||
Comment 15•21 years ago
|
||
> 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.
Updated•15 years ago
|
QA Contact: dunn5557 → mac
Comment 16•8 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•