Comment 1 hacker formerly known as seawood@netscape.com 2002-07-11 20:47:33 PDT

At a glance, it looks like asdecode doesn't like UFS.  Over to bryner.

Comment 2 Will Jenkins 2002-07-12 01:02:59 PDT

Is this not a duplicate of bug 86538?
http://bugzilla.mozilla.org/show_bug.cgi?id=86538

Comment 3 riscky 2002-07-12 11:45:00 PDT

Will, no bug 86538 is about runing Mozilla from a UFS drive. I am trying to
build mozilla from a USF drive. Also bug 86538 is for the CFM builds not mach-o.

This bug is more related to bug 133190 and bug 108300 (they are the only USF and
Macintosh building bugs I could find, thats the only way they are related.)

Comment 4 Brian Ryner (not reading) 2002-07-30 13:40:03 PDT

beard wrote asdecode, cc'ing him.  UFS probably doesn't like resource forks at
all.  Perhaps we should modify asdecode so that we can specify a filename for
the resource fork.  That would eliminate the extra copy step as well.

Comment 5 Steve Dagley 2002-07-31 08:04:52 PDT

beard is on sabbatical for a couple of more weeks (at least) so I hope you're
not waiting on him to change asdecode :-)

Comment 6 hacker formerly known as seawood@netscape.com 2002-12-01 15:22:34 PST

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

Comment 7 Conrad Carlen (not reading bugmail) 2003-01-31 10:48:28 PST

Created attachment 113216 [details]
.r version of libwidget.rsrc

This is a DeRez'd for of libwidget.r that I had around in my tree. I don't
still have the makefile changes, but they just used Rez -useDF instead of
asdecoding & copying.

Comment 8 Andrew Thompson 2003-04-23 22:42:54 PDT

Yeah. The simplest thing to do would be:

/Developer/Tools/DeRez MacWidget.rsrc > MacWidget.r

Then remove MacWidget.rsrc from CVS and add MacWidget.r.

Alter the Makefile to do this:

/Developer/Tools/Rez MacWidget.r -useDF -o libWidget.rsrc

Naturally one would have to add the appropriate directory names to the filenames
above. I'll see if I can get to this.

Comment 9 Andrew Thompson 2003-04-27 10:39:13 PDT

Created attachment 121856 [details] [diff] [review]
Remove need for Apple Single from 2 places in the tree

This patch removes the need for Apple Single when building 'widget' and the
Null Plugin. There's currently a third use in the tree at:

/plugin/oji/MRJCarbon/plugin/Resources/Makefile, line 3

but I think that's dead code.

Here's the approach:

For nsMacWidget.rsrc:

Comment 10 Andrew Thompson 2003-04-27 10:47:13 PDT

Created attachment 121857 [details] [diff] [review]
Remove need for Apple Single from 2 places in the tree

This patch removes the need for Apple Single when building widget/mac and
widget/cocoa and the Null Plugin. There's currently a fourth use in the tree
at:

/plugin/oji/MRJCarbon/plugin/Resources/Makefile, line 3

but I think that's dead code.

Here's the approach:

For widget/src/mac/nsMacWidget.rsrc:
    (i) simply checkin the data fork version of this resource file instead
    (ii) In Makefile.in just 'cp' it to the correct location in /dist/.

Works in my tree.

For NullPlugin.rsrc
    (i) DeRez the file into NullPlugin.r
    (ii) Replace the reference to _NullPlugin.rsrc in the ProjectBuilder
project
	 with a reference to NullPlugin.r
    (iii) Remove all reference to these files from Makefile.in (nothing for
Make
	 to do anymore)
    (iv) Remove NullPlugin.rsrc from CVS
Works in my tree.

For widget/src/cocoa/nsMacWidget.rsrc
    (i) This file is unused and should be removed from CVS. The Makefile.in in
widget/src/cocoa just refers to ../mac/nsMacWidget.rsrc.
    (ii) Patch alters Makefile.in to remove asdecode stuff as for
widget/src/mac

Comment 11 Brian Ryner (not reading) 2003-04-30 15:44:16 PDT

Yeah, we should do this.  I didn't do that before because I wanted the .rsrc
file to be shared between the CFM and Mach-O builds.  Now that we've abandoned
the CFM build, I don't see any reason not to use the approach here.

Comment 12 Brian Ryner (not reading) 2003-04-30 15:49:05 PDT

Comment on attachment 121857 [details] [diff] [review]
Remove need for Apple Single from 2 places in the tree

However, I like the approach in comment 8 better than the patch in attachment
121857 [details] [diff] [review].  We should prefer text files over binary for CVS; it makes things
easier for merging changes and seeing revision history.

Comment 13 Simon Fraser 2003-04-30 16:06:10 PDT

NullPlugin.r is covered by bug 179863.

Comment 14 Andrew Thompson 2003-05-04 18:30:32 PDT

Created attachment 122458 [details] [diff] [review]
Patch uses .r file as requested. Removed NullPlugin stuff as is handled by another bug

Comment 15 Andrew Thompson 2003-05-04 18:33:00 PDT

Created attachment 122460 [details] [diff] [review]
Run cvs diff in the correct directory this time!

Comment 16 Brian Ryner (not reading) 2003-05-08 01:35:49 PDT

Comment on attachment 122460 [details] [diff] [review]
Run cvs diff in the correct directory this time!

Looks good.  Can we get this in for 1.4 final?

Comment 17 Andrew Thompson 2003-05-08 06:04:08 PDT

I've no objections to checking it in.

Does this need a superreview too though?

Comment 18 (not reading, please use seth@sspitzer.org instead) 2003-05-08 06:46:04 PDT

Comment on attachment 122460 [details] [diff] [review]
Run cvs diff in the correct directory this time!

a=sspitzer for 1.4 final

Comment 19 Simon Fraser 2003-05-08 07:59:59 PDT

Comment on attachment 122460 [details] [diff] [review]
Run cvs diff in the correct directory this time!

I'd have a slight preference for the cocoa Makefile.in to follow the pattern we
use for other widget/src/mac files, which would be to make a symlink of the .r
in the export target. sr=sfraser with or without this change.

Comment 20 Andrew Thompson 2003-05-10 14:40:57 PDT

Simon: I tried to do this as a symlink, but it doesn't work. Presumably the
routine that opens the resource fork doesn't follow symlinks.

Bryner:

Thanks for checking this in and fixing the problem with Rez -i. Unfortunately
you've introduced 2 problems:

1) You didn't checkin nsMacWidget.r in the widget/src/COCOA directory, but the
Makefile.in in that directory expects to find it.

2) In bug 189719 varga@netscape.com had added 2 new cursors, resource #150 and
#151 to nsMacWidget.rsrc, but you lost them from the .r you checked in.

I guess that just goes to prove you were right when you said it's better to have
'.r' text based files in the tree than binary ones :)

I'll make a new .r and attach it presently. Let me know how to get it checked in.

Comment 21 Andrew Thompson 2003-05-10 15:41:06 PDT

Created attachment 122937 [details] [diff] [review]
Adds in the cursors that the previous patch accidentally removed

Comment 22 Andrew Thompson 2003-05-10 15:49:18 PDT

Of course, I was wrong about item (1).

For my benefit, I assume the line:

MAC_CPP_CSRCS   := $(addprefix $(srcdir)/../mac/,$(MAC_LCPPSRCS))

from widget/src/cocoa/Makefile.in allows it to find sources in ../mac ?

Comment 23 Simon Fraser 2003-05-12 09:04:37 PDT

Comment on attachment 122937 [details] [diff] [review]
Adds in the cursors that the previous patch accidentally removed

The Makefile in widget/src/cocoa has a list of cpp files in $(MAC_LCPPSRCS) in
src/mac, that are made relative in $(MAC_CPP_CSRCS), then symlinked in the
export phase. Bryner did this for nsMacWidget.r by adding
$(srcdir)/../mac/$(RES_SRC) to the export phase.

Comment 24 (not reading, please use seth@sspitzer.org instead) 2003-05-12 09:26:09 PDT

Comment on attachment 122937 [details] [diff] [review]
Adds in the cursors that the previous patch accidentally removed

a=sspitzer

Comment 25 Brian Ryner (not reading) 2003-05-13 16:00:07 PDT

checked in.