monolothic centralized package lists have go stale, are not configurable based on what you build. I wish these package lists were built up based on the makefile.
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall Engine
wish list move to m30
Taking advantage of new "Future" target milestone.
During my bug search for old and stale bugs I have come across this bug because if has not been changed since 2000-05-09. Is the issue in the bug still relevant (I cant tell from the description), then please let us know, or close the bug if it is no longer relevant.
This would still be a useful build change, don't close it.
Taking... as I outlined on npm.xpinstall and discussed a bit with deveditz, I think that I can kill several birds with one stone: 1) Move manifests into local trees, to be maintained and patched in a high-vibility location 2) Make manifests XP (for the most part) to reduce redundancy and mistakes 3) Make manifests multi-product, when appropriate... for example, the same manifest can be used for minimo, embedding, and gre/appsuite builds 4) Allow manifests to be conditionally build by Makefiles, so that they depend on the same configure flags as the rest of the tree My goal, at the end of this bug, is to flip the switch so that missing files cause errors during packaging, instead of warnings. This will increase the maintenance of the packaging system measurable, because it will cause tinderboxen to go red when patches alter packaged files. The basic premise is to have one or more .manifest files. During the MAKE process, these would be passed through Hixie's preprocessor (with a couple of extensions I'm adding to it). The format would be something like this: # comments: the following files are packaged when we build the # minimo, embedding, or gre packages. [minimo embed gre] @DIST@/@LIB@xpcom.@SO@ #ifdef WIN32 @DIST@/res/platformBindings.xml #endif
Created attachment 130634 [details] [diff] [review] Part 1, upgrade the preprocessor I'm going to do this incrementally, fixing any base architecture, creating or modifying the "manifest reader scripts" and then doing the gruntwork of splitting the existing package manifests into module-level (or lower) manifests. This upgrades the preprocessor to optionally handle @VAR@ substitution.
Comment on attachment 130634 [details] [diff] [review] Part 1, upgrade the preprocessor Hixie has checked-in a (slightly-altered) version of this patch.
Created attachment 130855 [details] [diff] [review] Part 2, add build system support for manifest files This adds build-system support for files... define the MANIFEST_FILES variable (and optionally add to MANIFEST_VARS/MANIFEST_DEFINES) and you will export the specified files to dist/manifest.
Comment on attachment 130855 [details] [diff] [review] Part 2, add build system support for manifest files oops, forgot GARBAGE, and I wanted to export LIBRARY instead of LIBRARY_NAME... update coming up
Comment on attachment 130912 [details] [diff] [review] Part 2, revisited cancelling reviews... I have cut a "working branch" for this bug PACKAGING_20030906_BRANCH (and an associated _BASE tag), and I will just try to get a review of the entire thing when I'm done.
Created attachment 133514 [details] [diff] [review] just the XPCOM changes, for review by dougt
Comment on attachment 133514 [details] [diff] [review] just the XPCOM changes, for review by dougt could you explain the changes to build/nsXPComInit.cpp; what are you trying to do?
Those changes are from bug 200091... if you register the GRE components before the app components, you don't need the check for new componentloaders, and it allows applications to cleanly override GRE component registration if necessary.
Comment on attachment 133514 [details] [diff] [review] just the XPCOM changes, for review by dougt Clearing review... the xpcom code changes were checked in to the trunk as part of bug 223900.
I don't think this will still be fixed, and if so, it probably doesn't belong to the SeaMonkey product.