358159 - stop using mac resource files (.rsrc) in widgets

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Josh Aas]

Right now we use libwidget.rsrc (in the tree as nsMacWidget.r), we should stop using resource files. They are old news and hard to deal with.

Comment 1

[Ray Kiddy]

In addition, they seem to cause build failures:

/Users/ray/mo/browser_20070810_121158_PDT/mozilla/config/nsinstall -L /Users/ray/mo/browser_20070810_121158_PDT/mozilla/widget/src/cocoa -m 755 libwidget_mac.dylib ../../../dist/bin/components
: ../../../dist/bin/components/libwidget_mac.dylib
nsIChangeManager.idl
../../../dist/bin/xpidl -m typelib -w -I. -I../../../dist/idl -e _xpidlgen/nsIChangeManager.xpt -d .deps/nsIChangeManager.pp nsIChangeManager.idl
nsIMenuCommandDispatcher.idl
../../../dist/bin/xpidl -m typelib -w -I. -I../../../dist/idl -e _xpidlgen/nsIMenuCommandDispatcher.xpt -d .deps/nsIMenuCommandDispatcher.pp nsIMenuCommandDispatcher.idl
nsPIWidgetCocoa.idl
../../../dist/bin/xpidl -m typelib -w -I. -I../../../dist/idl -e _xpidlgen/nsPIWidgetCocoa.xpt -d .deps/nsPIWidgetCocoa.pp nsPIWidgetCocoa.idl
../../../dist/bin/xpt_link _xpidlgen/widget_cocoa.xpt _xpidlgen/nsIChangeManager.xpt _xpidlgen/nsIMenuCommandDispatcher.xpt _xpidlgen/nsPIWidgetCocoa.xpt 
/Users/ray/mo/browser_20070810_121158_PDT/mozilla/config/nsinstall -L /Users/ray/mo/browser_20070810_121158_PDT/mozilla/widget/src/cocoa -m 644 _xpidlgen/widget_cocoa.xpt ../../../dist/bin/components
/Users/ray/mo/browser_20070810_121158_PDT/mozilla/config/nsinstall -D ../../../dist/bin/res/MainMenu.nib
/Users/ray/mo/browser_20070810_121158_PDT/mozilla/config/nsinstall -L /Users/ray/mo/browser_20070810_121158_PDT/mozilla/widget/src/cocoa resources/MainMenu.nib/classes.nib ../../../dist/bin/res/MainMenu.nib
/Users/ray/mo/browser_20070810_121158_PDT/mozilla/config/nsinstall -L /Users/ray/mo/browser_20070810_121158_PDT/mozilla/widget/src/cocoa resources/MainMenu.nib/info.nib ../../../dist/bin/res/MainMenu.nib
/Users/ray/mo/browser_20070810_121158_PDT/mozilla/config/nsinstall -L /Users/ray/mo/browser_20070810_121158_PDT/mozilla/widget/src/cocoa resources/MainMenu.nib/keyedobjects.nib ../../../dist/bin/res/MainMenu.nib
gmake[5]: stat:nsMacWidget.r: Too many levels of symbolic links
gmake[5]: *** No rule to make target `nsMacWidget.r', needed by `libwidget.rsrc'.  Stop.
gmake[4]: *** [libs] Error 2
gmake[3]: *** [libs] Error 2
gmake[2]: *** [libs_tier_gecko] Error 2
gmake[1]: *** [tier_gecko] Error 2
make: *** [default] Error 2

I am going to pull some things out of my mozconfig and see if that helps. Right now I have:

mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-debug
ac_add_options --enable-application=browser
ac_add_options --enable-test
ac_add_options --enable-gtktest
ac_add_options --enable-mochitest
ac_add_options --enable-libIDLtest
ac_add_options --enable-glibtest

Comment 2

[Ray Kiddy]

Nope. Cut the mozconfig down and it still failed in the same manner.

mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-application=browser

Comment 3

[Nick Kreeger]

I'm seeing the same thing as Ray... (Tbird trunk build, 10.4 - gcc 3.3)

Comment 4

[Josh Aas]

You may need to rebuild your tree from scratch. I moved that resource into the cocoa widgets dir from carbon.

Comment 5

[Ray Kiddy]

I do. Every time. I have a script which does the fresh checkout, configure and build. I e-mailed you the script.

Comment 6

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

"rebuild your tree from scratch" means "new folder for a new tree" or "clean/clobber on the existing tree and pull new/changed files", not merely "fresh checkout".

You can probably get by with just cleaning in widget/src/cocoa, but don't quote me on that, since it's been a while since the last time we moved old symlinked files from w/s/mac to w/s/cocoa, and I can no longer build to verify what I remember from before.

Comment 7

[Ray Kiddy]

Attachment: a script to make new directory, check out and build ff

Just to clarify for the wider audience, I am attaching my script. It does a "mkdir" of a new directory, goes into it, does a fresh checkout and configure and build. Given that others have seen this too, I might not be making a newbie mistake. It might be a real issue....

Comment 8

[Phil Ringnalda (:philor)]

Just in case anyone (like me) finds this bug rather than the proper one, comment 1 through comment 7 were actually looking for bug 378995 instead of this one.

Comment 9

[Josh Aas]

fixed by bug 464315