Re: Cross-platform packaging manifest

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