Clean up Windows packaging on the trunk

RESOLVED FIXED in Thunderbird 3.1a1

Status

RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: philor, Assigned: philor)

Tracking

Trunk
Thunderbird 3.1a1
x86
Windows 7
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

9 years ago
In three steps, I think, since I keep getting tangled up when I try to do it in one. We need to drop the 1_9_1 ifdefs, except that sometimes we need to change them to 1_9_2 ifdefs when we did them before we started thinking about 1_9_2; we need to do some catchup/cleanup; and we need to fix the packaging of shared builds for tests in the post bug 514665 world.
(Assignee)

Comment 1

9 years ago
Created attachment 413866 [details] [diff] [review]
1.9.1 ifdefs -> 1.9.2 ifdefs [checked in]

Slightly different split than I thought, because I always underestimate what an annoyance testing removed-files.in is. So, two easy ones, moving some of the 1.9.1 ifdefs to 1.9.2 ifdefs and removing others, then cleaning up static packaging, then a few days of building and testing 1.9.1 -> 1.9.2 < -- > 1.9.3 updates for a removed-files.in patch, then shared.
Attachment #413866 - Flags: review?(bugzilla)
(Assignee)

Comment 2

9 years ago
Created attachment 413867 [details] [diff] [review]
static cleanup [checked in]

Just a couple of things, really, packaging msgAsyncPrompter.js and shuffling the things that Taras is now jarring into a 1.9.2 ifdef.
Attachment #413867 - Flags: review?(bugzilla)
(Assignee)

Comment 3

9 years ago
(In reply to comment #1)
> 1.9.1 -> 1.9.2 < -- > 1.9.3

Unless that needs a triple arrow, we still need to make a decision we're sure we like about downgrading to a stable build.
(Assignee)

Comment 4

9 years ago
Ack ulp. I thought the removed-files.in thing was going to be fairly easy and clean, until I realized that while we're getting XPTs linked on Linux on 1.9.2 and 1.9.3, we're only getting them linked on OS X on 1.9.3.

#ifdef XP_MAC_OSX
#ifndef MOZILLA_1_9_2_BRANCH
#define REMOVE_UNLINKED_XPTS
#endif
#elifdef UNIX_BUT_NOT_MAC
#define REMOVE_UNLINKED_XPTS
#endif

#ifdef REMOVED_UNLINKED_XPTS

maybe?

Or just suck it up and do a single preprocessed manifest for all three platforms, so we get them linked because of the manifest, before we ship anything off 1.9.2 and have to worry about it?
(In reply to comment #4)
> Or just suck it up and do a single preprocessed manifest for all three
> platforms, so we get them linked because of the manifest, before we ship
> anything off 1.9.2 and have to worry about it?

Let's go with the single manifest. Although it means a bit of extra work, getting a bit more startup perf on Mac doesn't hurt and means we'll package what we're expecting on all platforms. Additionally I'd be tempted to try and uplift our package-compare so that we fail build if it looks wrong (I'm not convinced that is entirely possible yet).

We'll still take these existing patches though as I expect that will help with the cleanup.
(Assignee)

Comment 6

9 years ago
Created attachment 414445 [details] [diff] [review]
removed-files.in cleanup, round 1 [checked in]

Not complete, since there's a bit of Mac stuff left for the trunk and a ton for 1.9.2-as-it-is-now, but this gets us clean on Windows and Linux, and cleaner on Mac.
Attachment #414445 - Flags: review?(bugzilla)
(Assignee)

Comment 7

9 years ago
I'd love to see a strict package compare, but it would probably need to be orange rather than red - it'd have to be the result of expanding something like NO_PKG_FILES to cover every single thing we know we don't want to package, and then we'd be at the mercy of mozilla-central, and NSS, and NSPR, burning us by throwing crap into dist/bin/. Much as I like the sound of bsmedberg's "packaging should just be a matter of shipping every single thing in dist/bin/, and if it doesn't ship it doesn't belong there" I don't see that actually happening.
Comment on attachment 413867 [details] [diff] [review]
static cleanup [checked in]

This is good. I tested against 1.9.2 and trunk and it looks fine.

Note that try server now does the package-compare step so we can test patches better :-)
Attachment #413867 - Flags: review?(bugzilla) → review+
Comment on attachment 413866 [details] [diff] [review]
1.9.1 ifdefs -> 1.9.2 ifdefs [checked in]

So I meant to mark this one first, but it works as well ;-)
Attachment #413866 - Flags: review?(bugzilla) → review+
Blocks: 523820
(Assignee)

Comment 10

9 years ago
Comment on attachment 413866 [details] [diff] [review]
1.9.1 ifdefs -> 1.9.2 ifdefs [checked in]

http://hg.mozilla.org/comm-central/rev/0febcd1aa401
Attachment #413866 - Attachment description: 1.9.1 ifdefs -> 1.9.2 ifdefs → 1.9.1 ifdefs -> 1.9.2 ifdefs [checked in]
(Assignee)

Comment 11

9 years ago
Comment on attachment 413867 [details] [diff] [review]
static cleanup [checked in]

http://hg.mozilla.org/comm-central/rev/4067a09e89dc
Attachment #413867 - Attachment description: static cleanup → static cleanup [checked in]
Comment on attachment 414445 [details] [diff] [review]
removed-files.in cleanup, round 1 [checked in]

>+components/fts3tok.xpt

Where does this come from? I can't see it referenced anywhere.

r=Standard8 without that, or with a good explanation of where it comes from.
Attachment #414445 - Flags: review?(bugzilla) → review+
(Assignee)

Comment 13

9 years ago
It comes from http://mxr.mozilla.org/comm-central/source/mailnews/extensions/fts3/public/Makefile.in#46 - it's the SQLite full text searching from bug 472764, one of the four things that started creating XPTs between the time I landed that list and when we froze enough that I can call the current list close enough to "what we shipped with 3.0," which once I finish the accursed single package-manifest.in will be the last time we'll ship unlinked XPTs.

Unless you meant that I misspelled it, but if I copy-paste it from your comment, http://mxr.mozilla.org/comm-central/search?string=fts3tok.xpt says that's something we package.
(Assignee)

Comment 14

9 years ago
Comment on attachment 414445 [details] [diff] [review]
removed-files.in cleanup, round 1 [checked in]

http://hg.mozilla.org/comm-central/rev/c34539144f1f
Attachment #414445 - Attachment description: removed-files.in cleanup, round 1 → removed-files.in cleanup, round 1 [checked in]
(Assignee)

Comment 15

9 years ago
I think I'll call that enough for this bug - anything else I do right now will just be bit-rotting me for bug 533043
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Comment on attachment 414445 [details] [diff] [review]
removed-files.in cleanup, round 1 [checked in]

>+res/broken-image.gif
> res/cmessage.txt
>-#ifndef MOZILLA_1_9_1_BRANCH
>-res/broken-image.gif

Wrt bug 521293, did you not add things like the following on purpose?
{
#ifndef MOZILLA_1_9_2_BRANCH
res/broken-image.png
#endif
}
Wrt bug 523820, even if not the main point of this bug, could you remove the remaining 1.9.1 ifdef too:
http://mxr.mozilla.org/comm-central/search?string=1%5B%5C._%5D9%5B%5C._%5D1&regexp=on&case=on&find=%2Fmail%2F
"Found 7 matching lines in 3 files"
Depends on: 338549
You need to log in before you can comment on or make changes to this bug.