Closed Bug 20640 Opened 25 years ago Closed 16 years ago

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

Categories

(SeaMonkey :: Installer, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: dougt, Unassigned)

References

Details

Attachments

(1 file, 3 obsolete files)

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
Target Milestone: M17
Status: NEW → ASSIGNED
wish list
move to m30
Target Milestone: M17 → M30
Target Milestone: M30 → Future
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.
Severity: normal → enhancement
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
Assignee: dveditz+bmo → bsmedberg
Status: ASSIGNED → NEW
Severity: enhancement → normal
Component: Installer: XPInstall Engine → Installer: XPI Packages
Priority: P3 → --
Target Milestone: Future → ---
Attached patch Part 1, upgrade the preprocessor (obsolete) — Splinter Review
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.
Attachment #130634 - Flags: review?(ian)
Comment on attachment 130634 [details] [diff] [review]
Part 1, upgrade the preprocessor

Hixie has checked-in a (slightly-altered) version of this patch.
Attachment #130634 - Flags: review?(ian)
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.
Attachment #130634 - Attachment is obsolete: true
Attachment #130855 - Flags: review?(cls)
Attachment #130855 - Flags: review?(cls)
Attachment #130855 - Flags: superreview?(dveditz+bmo)
Attachment #130855 - Flags: review?(leaf)
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
Attachment #130855 - Attachment is obsolete: true
Attachment #130855 - Flags: superreview?(dveditz+bmo)
Attachment #130855 - Flags: review?(leaf)
Attached patch Part 2, revisited (obsolete) — Splinter Review
Attachment #130912 - Flags: superreview?(dveditz+bmo)
Attachment #130912 - Flags: review?(bryner)
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.
Attachment #130912 - Flags: superreview?(dveditz+bmo)
Attachment #130912 - Flags: review?(bryner)
Depends on: 219233
Attachment #130912 - Attachment is obsolete: true
Attachment #133514 - Flags: review?(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.
Attachment #133514 - Flags: review?(dougt)
Depends on: 230335
Priority: -- → P1
Product: Browser → Seamonkey
Priority: P1 → P3
Target Milestone: --- → Future
Assignee: benjamin → nobody
Component: Installer: XPI Packages → Installer
QA Contact: jimmykenlee → general
Priority: P3 → --
Target Milestone: Future → ---
I don't think this will still be fixed, and if so, it probably doesn't belong to the SeaMonkey product.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: