Closed
Bug 179863
Opened 22 years ago
Closed 16 years ago
Build the default plugin as Mach-O, with resources in a .r file
Categories
(Core Graveyard :: Plug-ins, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.5alpha
People
(Reporter: sfraser_bugs, Assigned: mark)
References
Details
(Keywords: topembed+)
Attachments
(2 files, 2 obsolete files)
40.42 KB,
patch
|
netscape
:
review+
bryner
:
superreview+
|
Details | Diff | Splinter Review |
7.36 KB,
text/plain
|
sfraser_bugs
:
review+
sfraser_bugs
:
superreview+
|
Details |
We need to build the default plugin as Mach-O for Mach-O mozilla. There is a patch here: http://bugzilla.mozilla.org/attachment.cgi?id=104548&action=view that does this.
Comment 1•22 years ago
|
||
*** Bug 191010 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Reporter | ||
Comment 2•22 years ago
|
||
This patch was merged from the Chimera branch. Note that it builds the plugin, but does not copy it to dist/bin yet.
Reporter | ||
Comment 3•22 years ago
|
||
The makefile does actually create a symlink to the built plugin in dist/bin/plugins.
Reporter | ||
Updated•22 years ago
|
Attachment #113521 -
Flags: superreview?(bryner)
Attachment #113521 -
Flags: review?(cls)
Comment 4•22 years ago
|
||
Comment on attachment 113521 [details] [diff] [review] Patch to build default plugin as Macho There's no need to duplicate the all:: rule since it's not being used as the default rule (you included rules.mk before that rule). The dependency for the libs:: ruleset should be enough. Also, the install:: ruleset should be different per bug 56601. It should install the plugin under $(DESTDIR)$(mozappdir)/plugins or be left out completely (since 'make install' probably won't work as expected on OSX). Also, you should change the ASDECODE definition to use $(DIST)/bin instead of hardcoding the ../../....
Attachment #113521 -
Flags: review?(cls) → review-
Reporter | ||
Comment 5•22 years ago
|
||
Attachment #113521 -
Attachment is obsolete: true
Reporter | ||
Updated•22 years ago
|
Attachment #113533 -
Flags: superreview?(bryner)
Attachment #113533 -
Flags: review?(cls)
Comment 6•22 years ago
|
||
Comment on attachment 113533 [details] [diff] [review] Fixed Makefile fu r=cls
Attachment #113533 -
Flags: review?(cls) → review+
Comment 7•22 years ago
|
||
Comment on attachment 113533 [details] [diff] [review] Fixed Makefile fu This is going to fail for objdir builds, just like Conrad's original patch in bug 186036. Trunk Mach-O builds need to work in objdirs. Is there a reason why this needs to be a projectbuilder project, instead of just being built with make?
Attachment #113533 -
Flags: superreview?(bryner) → superreview-
Updated•22 years ago
|
Attachment #113521 -
Flags: superreview?(bryner)
Reporter | ||
Comment 8•22 years ago
|
||
Crud. It's a PB project because PB does the packaging nicely for us. Otherwise, we'd have to have a checked-in package hierarchy, and copy the resulting binary into it (which is what we do for Mozilla.app, I guess).
Comment 9•21 years ago
|
||
setting 1.4a?, the default plugin isn't currently being included in Mach-O seamonkey builds plus it's a good working sample for developers. It doesn't look too bad to checkin the project file as was done in bug 186036.
Flags: blocking1.4a?
Reporter | ||
Comment 10•21 years ago
|
||
This patch requires that the patch in bug 199567 has been applied.
Attachment #113533 -
Attachment is obsolete: true
Reporter | ||
Updated•21 years ago
|
Attachment #118773 -
Flags: superreview?(bryner)
Attachment #118773 -
Flags: review?(seawood)
Comment 11•21 years ago
|
||
Comment on attachment 118773 [details] [diff] [review] Build the default plugin as Mach-O, and fix Makefile.in for objdir builds In samples/default/mac/Makefile.in, ASDECODE should be set to $(DIST)/bin/asdecode rather than hardcoding the depth. Fix that && r=cls.
Attachment #118773 -
Flags: review?(seawood) → review+
Updated•21 years ago
|
Flags: blocking1.4a? → blocking1.4a-
Updated•21 years ago
|
Attachment #118773 -
Flags: superreview?(bryner) → superreview+
Reporter | ||
Comment 12•21 years ago
|
||
Checked in.
Reporter | ||
Comment 13•21 years ago
|
||
Fixed, really.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 14•21 years ago
|
||
+# decodes resource files from AppleSingle to Resource Manager format. +ASDECODE = ../../../../../dist/bin/asdecode +RESOURCE_FILES = _NullPlugin.rsrc This isn't good. While we're reworking these projects, we should be getting rid of .rsrc files and replacing them with .r files. Binary resource files cause problems for those trying to build on UFS disks, and editing them is really hard. Also, it requires all this jazz in the Makefile. With a .r file, stick it in the PB project, and that's it. I'll attach the .r file. Another problem: the size of the plugin exec in the nightly build is 216KB. I believe that the "Deployment" build style is building with debug symbols. While "COPY_PHASE_STRIP" is on in the Deployment Build Style, that doesn't do anything unless you pass "-install" to pbxbuild. Is it possible that the large size of this plugin and that it has debug symbols is what sharply increased Ts when it was checked in?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 15•21 years ago
|
||
Reporter | ||
Comment 16•21 years ago
|
||
I don't mind strings in .r files, but putting cicns in them seems stupid. Project builder (and UFS) should be fine with datafork-based resource files; can't we just use those instead?
Comment 17•21 years ago
|
||
> Project builder (and UFS) should be fine with datafork-based resource files;
can't we just use those instead?
ResEdit won't work on data fork files, so that would take work. It's really not
so bad to have cursors and such in .r files - just Rez -> edit -> DeRez. It's
really not any harder than asdecoding, or converting between data-fork and
res-fork files to edit.
Updated•21 years ago
|
Priority: P2 → P1
QA Contact: shrir → bmartin
Reporter | ||
Comment 18•21 years ago
|
||
Comment on attachment 119974 [details]
NullPlugin.r
Let's get this in.
Attachment #119974 -
Flags: superreview+
Attachment #119974 -
Flags: review+
Updated•21 years ago
|
Target Milestone: --- → mozilla1.4final
Comment 20•21 years ago
|
||
can this be marked FIXED? I see the default plugin in today's Mach-O mozilla build.
Reporter | ||
Comment 21•21 years ago
|
||
It really is fixed; it was reopened for the .r change. Let's move that out.
Status: REOPENED → ASSIGNED
Priority: P1 → P2
Summary: Build the default plugin as Mach-O → Build the default plugin as Mach-O, with resources in a .r file
Target Milestone: mozilla1.4final → mozilla1.5alpha
Assignee | ||
Comment 22•18 years ago
|
||
Bug 322578 makes this a resource-in-data .rsrc file.
Setting this back to FIXED, based on comment 21 and comment 22 (and bug 322578 comment 1).
Status: NEW → RESOLVED
Closed: 21 years ago → 16 years ago
Resolution: --- → FIXED
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•