Closed
Bug 356727
Opened 18 years ago
Closed 16 years ago
Remove useless binaries from the package
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mozilla, Assigned: mozilla)
Details
Attachments
(1 file, 1 obsolete file)
779 bytes,
patch
|
kairo
:
review+
neil
:
superreview+
|
Details | Diff | Splinter Review |
From the discussion in de.comm.software.mozilla.browser: regxpcom is probably useless in SeaMonkey builds but is still shipped in the packages. It should not get packaged any more. Similar files that should probably not get shipped are the xpidl xpt_dump xpt_link xpcshell dirver executables. None of these come with Firefox any more. xpicleanup is needed AFAIK and is the only executable still coming with Firefox.
Assignee | ||
Comment 1•18 years ago
|
||
The same probably also applies to Thunderbird. At least on OS/2 the exes mentioned get packaged.
Comment 2•18 years ago
|
||
At least xpcshell is sometimes used for testing. When you're making a release build, --disable-tests should be set anyway. How do you make a package for OS/2 btw? As in what command do you need to execute to get a zip/installer.
Assignee | ||
Comment 3•18 years ago
|
||
The list of files in comment 0 was actually taken from a Linux package that I made with "make -C obj/xpinstall/packager", compared with a Linux Firefox package I got from mozilla.org. In my SeaMonkey build I did use --disable-tests (if not, there would be a lot more useless binaries). If xpcshell (or one of the other binaries) is useful to users then leave it in. Developers have the binaries in the tree anyway and extension developers should be able to get the tools from a gecko-sdk package, if they need them, right? On OS/2 you use the same commands as to my knowledge everywhere else ZIP package: make -C obj/xpinstall/packager Installer: make -C obj/xpinstall/packager installer
Comment 4•16 years ago
|
||
This bug related to trunk an reasonably old to be resolved as Incomplete.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Comment 5•16 years ago
|
||
It doesn't make sense to resolve a bug incomplete just based on age. All the information is there and it just needed a decision from some developers to create a patch and resolve it. [But I see that none of them are CC'd to this bug (any more?) so that's probably why they didn't react.] In the meantime, the problem seems to have been solved on Linux and Windows so we just need to remove xpcshell.exe xpidl.exe xpt_dump.exe xpt_link.exe from OS/2 packages. Hmm, Linux doesn't even contain regxpcom any more, I wonder why that is.
Status: RESOLVED → UNCONFIRMED
OS: All → OS/2
Hardware: All → PC
Resolution: INCOMPLETE → ---
Assignee | ||
Comment 6•16 years ago
|
||
Now that it's OS/2 only I can work on it.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 7•16 years ago
|
||
Just in case you don't already know how things wind up not packaged, there are three places: with a MOZ_PKG_MANIFEST(_P) (suite's "packages", browser's "packages-static") you get just those things (so that covers Windows for everything, and Linux for suite and browser, but not mail), without, you get everything except the things listed in NO_PKG_FILES, in app/installer/Makefile.in and in toolkit/mozapps/installer/packager.mk. So you don't get those .exes in Firefox because it's adding them to NO_PKG_FILES in browser/installer/Makefile.in.
Assignee: nobody → mozilla
Status: ASSIGNED → NEW
Assignee | ||
Comment 8•16 years ago
|
||
Hmm, I haven't actually found out where the files are removed by the packaging process on Windows and Linux but this patch removes them for OS/2, even though it's not really an elegant solution.
Attachment #311799 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 9•16 years ago
|
||
Oops, Phil, thanks. I didn't read your comment before posting the patch. Will probably revise the patch.
Assignee | ||
Updated•16 years ago
|
Attachment #311799 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 10•16 years ago
|
||
OK, as Phil said this is how FF and TB do it, I think SM should just follow.
Attachment #311799 -
Attachment is obsolete: true
Attachment #315867 -
Flags: superreview?
Attachment #315867 -
Flags: review?(kairo)
Assignee | ||
Updated•16 years ago
|
Attachment #315867 -
Flags: superreview? → superreview?(neil)
Comment 11•16 years ago
|
||
Comment on attachment 315867 [details] [diff] [review] patch v2 The thing is, they're useful for extension developers...
Assignee | ||
Comment 12•16 years ago
|
||
But Neil, you are already not packaging them on Windows and Linux, this will just do the same for OS/2 which so far is not the case because we don't have a package manifest. I can move it into an ifdef OS2 section if that makes you feel more comfortable.
Comment 13•16 years ago
|
||
Comment on attachment 315867 [details] [diff] [review] patch v2 Personally I would have thought that these binaries would be useful to extension authors, but if we aren't shipping them anywhere else either...
Attachment #315867 -
Flags: superreview?(neil) → superreview+
Comment 14•16 years ago
|
||
Comment on attachment 315867 [details] [diff] [review] patch v2 yes, doing the same as FF here sounds good. r=me.
Attachment #315867 -
Flags: review?(kairo) → review+
Assignee | ||
Comment 15•16 years ago
|
||
Thanks for the reviews, patch checked into trunk. (It seems that extension developers who need those files are expected to compile themselves, but I'm also surprised that nobody has complained about that yet. Perhaps it just isn't well know that these tools could be useful for them.)
Status: NEW → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•