179863 - Build the default plugin as Mach-O, with resources in a .r file

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Simon Fraser [no longer active]]

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

[Peter Lubczynski]

*** Bug 191010 has been marked as a duplicate of this bug. ***

Comment 2

[Simon Fraser [no longer active]]

Attachment: Patch to build default plugin as Macho

This patch was merged from the Chimera branch. Note that it builds the plugin,
but does not copy it to dist/bin yet.

Comment 3

[Simon Fraser [no longer active]]

The makefile does actually create a symlink to the built plugin in dist/bin/plugins.

Comment 4

[hacker formerly known as [e-mail]]

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 ../../....

Comment 5

[Simon Fraser [no longer active]]

Attachment: Fixed Makefile fu

Comment 6

[hacker formerly known as [e-mail]]

Comment on attachment 113533 [details] [diff] [review]
Fixed Makefile fu

r=cls

Comment 7

[Brian Ryner (not reading)]

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?

Comment 8

[Simon Fraser [no longer active]]

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

[Peter Lubczynski]

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.

Comment 10

[Simon Fraser [no longer active]]

Attachment: Build the default plugin as Mach-O, and fix Makefile.in for objdir builds

This patch requires that the patch in bug 199567 has been applied.

Comment 11

[hacker formerly known as [e-mail]]

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.

Comment 12

[Simon Fraser [no longer active]]

Checked in.

Comment 13

[Simon Fraser [no longer active]]

Fixed, really.

Comment 14

[Conrad Carlen (not reading bugmail)]

+# 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?

Comment 15

[Conrad Carlen (not reading bugmail)]

Attachment: NullPlugin.r

Comment 16

[Simon Fraser [no longer active]]

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

[Conrad Carlen (not reading bugmail)]

> 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. 

Comment 18

[Simon Fraser [no longer active]]

Comment on attachment 119974 [details]
NullPlugin.r

Let's get this in.

Comment 19

[Samir Gehani]

adt: nsbeta1-

Comment 20

[Peter Lubczynski]

can this be marked FIXED? I see the default plugin in today's Mach-O mozilla build.

Comment 21

[Simon Fraser [no longer active]]

It really is fixed; it was reopened for the .r change. Let's move that out.

Comment 22

[Mark Mentovai]

Bug 322578 makes this a resource-in-data .rsrc file.

Comment 23

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Setting this back to FIXED, based on comment 21 and comment 22 (and bug 322578 comment 1).