Created attachment 283707 [details] [diff] [review] handle extension more flexibly in tinderbox I've tried to create a tinderbox for venkman to produce regular [nightly] packages for it and realized tinderbox can be used for this quite nicely for the most part. Using the extensions/ dir created in dist/bin as $BinaryName for it is a hack of some sort but works out nicely as long as we don't end up pointing $Settings::DistBin somewhere else because we happen to be on a mac, so I coded up a small change to make this case work. When it comes to uploading, we already have some code in post-mozilla-rel.pl to upload Lightning and xforms specifically - I figured if we replace this with generic handling, we reduce code, make stuff clearer and are able to handle cases like mine as well. I ended up with adding to options to config, one giving a glob pattern to copy from xpi-stage/ to our upload dir, and one for putting the extension in platforms-xpi/ subdirs or not. This works fine on my mac tinderbox with both normal trees that build SeaMonkey (where this does nothing) and on the venkman build listed on MozillaTest atm that has |$ReleaseExtension = "venkman*.xpi";| set in tinder-config.pl
Oh, I forgot, to make the Lightning tinderboxen do the same thing as they are now with this patch, we'd need to add $ReleaseExtension = "lightning*.xpi"; $ReleaseExtensionPlatform = 1; to their tinder-config.pl files - similar things need to be done if we happen to have boxes somewhere that actually use the xforms stuff, $ReleaseExtension can probably be set to plain "xforms.xpi" there. Unless the build process of the extension itself needs it, we could even go as far as to have the tinderboxen build only Lightning and no complete Thunderbird with this patch.
Comment on attachment 283707 [details] [diff] [review] handle extension more flexibly in tinderbox Apparently, bug 410922 also covers at least part of this, clearing review for now.
I've had a conversation with Philipp who did work on bug 410922 and we agreed that the clean solution fitting all of us would be to have the following settings: @ReleaseExtensions, which is empty be default and can set to a list that even can contain wildcards, e.g. ('lightning*.xpi', 'gdata-provider.xpi'); $ReleaseExtensionSubdir, which is an empty string by default and makes us use the platform subdirs. If set to a non-empty string, that subdir is created and used for extensions upload. I propose that a value of "." should use the main FTP directory, not creating a subdir for extensions. The patch for bug 410922 basically implements that (though I'm not sure how well wildcards and the "." value have been tested yet), we'll extend the work from that bug in here to also cover the cases I have been targeting here.
Created attachment 296649 [details] [diff] [review] patch v2: improved handling of extensions in tinderbox This new patch does the following: 1) Allow the use of the extensions/ dir created in dist/bin as $BinaryName so that an extensions-only tinderbox can work. 2) Remove explicit handling of xforms in favor of the new generic mechanism for extensions, that includes handling of an eventual os2-xpi/ directory for those. 3) Handle wildcards when determining if an extension to upload has been found. 4) Only create $extensionStageDir when it doesn't exist yet. 5) Remove the -r option from the cp command for extensions. We'll need to patch 1.8 branch Firefox tinderbox configs for still handling xforms upload, I'll attach it in a second.
Created attachment 296652 [details] [diff] [review] patch Firefox 1.8 branch tinderbox configurations This patches the Firefox tinderbox configurations for 1.8 branch to still upload xforms XPIs. Note that I'm cleaning up double-use of the $BuildXForms veraible in those tinder-config files as well.
Comment on attachment 296652 [details] [diff] [review] patch Firefox 1.8 branch tinderbox configurations Good catch with the double definition of XForms.
Checked in both patches. From what I see, at least the Linux 1.8 box still uploads XForms and everything stayed green :)