20640 - [wish] install package list should be build by the makefiles

Status: RESOLVED WONTFIX

(SeaMonkey :: Installer, defect)

Description

[Doug Turner (:dougt)]

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.

Comment 1

[leger]

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine

Comment 2

[Cathleen]

wish list
move to m30

Comment 3

[Daniel Veditz [:dveditz]]

Taking advantage of new "Future" target milestone.

Comment 4

[Henrik Lynggaard Hansen]

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.

Comment 5

[Daniel Veditz [:dveditz]]

This would still be a useful build change, don't close it.

Comment 6

[Benjamin Smedberg]

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

Comment 7

[Benjamin Smedberg]

Attachment: 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 8

[Benjamin Smedberg]

Comment on attachment 130634 [details] [diff] [review]
Part 1, upgrade the preprocessor

Hixie has checked-in a (slightly-altered) version of this patch.

Comment 9

[Benjamin Smedberg]

Attachment: 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 10

[Benjamin Smedberg]

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 11

[Benjamin Smedberg]

Attachment: Part 2, revisited

Comment 12

[Benjamin Smedberg]

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.

Comment 13

[Benjamin Smedberg]

Attachment: just the XPCOM changes, for review by dougt

Comment 14

[Doug Turner (: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?

Comment 15

[Benjamin Smedberg]

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 16

[Benjamin Smedberg]

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.

Comment 17

[Robert Kaiser]

I don't think this will still be fixed, and if so, it probably doesn't belong to the SeaMonkey product.