Forwarding back to the newsgroup > Some thoughts I've had on the subject are sort of covered by > http://bugzilla.mozilla.org/show_bug.cgi?id=22062 > > In short, separate chunks of the tree should have their own *.pkg files and > export them to a dist directory as needed. If you don't build mail, don't > export mail.pkg. At the appropriate install build step run the package > copying scripts on *.pkg > > Will order be a problem? I know the Netscape build used its package list to > delete or override some of the Mozilla files. That would still work because > the Netscape build was a separate step, but makes me wonder if Mozilla might > end up needing something similar. > > This could be done without much change to the current package copying > script. Something pure XUL/JS like chatzilla could have a single > chatzilla.pkg, something with binary components like GRE could have three > different package files and export the appropriate one at the build step. > > [One flaw: the Mac uses "viewer" as the root directory, everything else uses > "bin". We should fix the mac build system, but if we don't we'll need some > sort of Macro ability in the package files. We probably want that anyway] > > I would expand on your platform sections and make them a more flexible IFDEF > system instead. We definitely have platform differences, but we might also > have other build differences where an IFDEF would really come in handy. Some > optional builds could easily be covered by adding another *.pkg file, but if > there were build options that needed to remove or overwrite files an IFDEF > would help us avoid getting into *.pkg order issues. > > As your {.so} example shows, as well as the viewer/bin issue, we need a > macro replacement syntax. For familiarity we could use makefile $(VAR) > syntax and have the pkgcpy.pl script accept those as arguments, and possibly > even fall back on environment variables the way make does. > > We could similarly automate .xpi creation: as the build progresses export > *.jst files, and at the end for every foo.jst found create foo.xpi using > files copied to $(STAGE)/foo by the package list scripts. > > And lastly, to create native install packages we'll need to process all > exported *.it files and use some kind of manifests to say which files need > to be globbed together. The manifests will need some sort of renaming > facility (use the package list comma syntax to reduce brainprint?) so we can > have things like config-gre and config-firebird renamed to config.ini in the > actual packages. > > While we're redesigning things the .jst files need to support some kind of > #include syntax so we don't have the build scripts slapping a common > prologue of utility routines into every script whether needed or not. > > We need a way to include or exclude optionally built components into an > install package, too, rather than multiplying with-and-without-chatzilla, > with-and-without-spellchecker, with-spellchecker-and-chatzilla, etc > config.it and manifest files. I guess that means supporting an IFDEF like > syntax in those two file types as well. The current component numbering > scheme in config.it will complicate things a bit but maybe Sean will come up > with something :-) > > I think this meshes with Benjamin's proposal, if not please tell me what > I've misunderstood. > > -Dan Veditz > > Benjamin Smedberg wrote: > >>I have had several bugs recently that required changes to the packaging >>manifests in xpinstall/packager and embedding/config. Most of these >>changes were exactly the same on each platform, and involved lots of >>grunt work and potential for error. >> >>In addition, many of the embedding and GRE manifests in embedding/config >>duplicate the manifests in xpinstall/packager. >> >>I have been thinking of a way of combining these manifests in a tiered, >>cross-platform manner. >> >>GOALS: >> >>1) to reduce the number of files that must be touched when a patch >>alters packaging >>2) to increase the clarity of which manifests package which products >> >>PROPOSAL: >> >>I think that we can "tier" packaging files like so: >>minimo.manifest >>embedding.manifest >>GRE.manifest >>XRE.manifest (if/when this ever happens) >> >>Then, each application (seamonkey/*Bird) would have an >>application-specific packaging script (in the case of seamonkey, >>multiple scripts, one for each XPI (browser/mail/etc). >> >>The format of each packaging script would be unified so that we could >>use the same format for all platforms, without worrying about >>differences (lib*.so/*.dll/.shlb). Also, each file could have optional >>platform-specific sections. Something like this: >> >>ALL >> components/intl.xpt >> res/charsetalias.properties >> res/charsetData.properties >> res/langGroups.properties >> res/language.properties >> >>ALL-NONSTATIC >> components/{lib}i18n.{so} >> >>UNIX >> res/unixcharset.properties >> >>WIN32 >> res/wincharset.properties >> >>MAC >> res/maccharset.properties
