313185 - Allow components to place files at arbitrary locations in Mac bundles (.app)

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Mark Mentovai]

Josh expressed interest in having the Cocoa widget library put a .nib in each
application's Contents/Resources/*.lproj directory.  Our build system doesn't
support that kind of thing right now.  The bundle is only structured immediately
after the final link, and there's no opportunity for prerequisites to place
files or directories in arbitrary locations of the .app package.

Comment 1

[Mark Mentovai]

Attachment: Patch

This introduces three Makefile variables that can be set before rules.mk is
included: MAC_CONTENTS, MAC_RESOURCES, and MAC_RESOURCES_LPROJ.  They can
contain lists of files that belong, respectively, in *.app/Contents,
*.app/Resources, and *.app/Resources/$(AB).lproj.  It also contains updates to
the Makefiles for Firefox, Thunderbird, and Seamonkey to initialize the app
bundle with files that had been placed according to these variables.

Eventually, I'd like to migrate much of what's in the "macbuild" directories
now to also use this new system.

Comment 2

[Mark Mentovai]

Comment on attachment 200266 [details] [diff] [review]
Patch

Josh, give this patch a try.  In widget/src/cocoa/Makefile.in, you will want to
do something along these lines before rules.mk is included:

MAC_RESOURCES_LPROJ = $(srcdir)/MainMenu.nib

Comment 3

[Benjamin Smedberg]

Why do we need to use the mac-specific l10n files instead of our traditional
DTD+properties based localization techniques? This will significantly and
negatively impact localization unless I don't understand what we're actually
trying to accomplish.

Please note that I have some unformed plan to build directly into
dist/Foo.app/Content/MacOS instead of building to dist/bin and then rsync'ing
everything over. We should discuss how all of these things fit together.

Comment 4

[Mark Mentovai]

This isn't for l10n per se, but for Mac-specific resources that need to be
located at precise points in the app bundle.  The traditional point for nibs is
in the lproj, even if there's no need for l10n.

(As a side note, I also hope that one day, we can move our l10n jar out of
Contents/MacOS/chrome and into Resources/*.lproj - this would make it trivial to
prepare a "fat" multilingual bundle that respects the system language preferences.)

I assume that when your plan materializes, we could use the same variables to
nsinstall things directly into the app instead of into macbundle as I'm doing
here, so the only thing that would need to change is the target directory in
rules.mk.  Let me know if and when you want to discuss.

Comment 5

[Benjamin Smedberg]

Just to be clear, I am worried about this on a whole lot of levels, not just for
l10n: we're talking about widget resources, which must end up living the
XUL.framework bundle (XULRunner), not the application bundle. I'm interested in
knowing the precise needs (in terms of MacOS API calls) and how we can service
those needs with a minimum of mac-specific bundle hacking.

Comment 6

[Mark Mentovai]

When widget is built into XULRunner, I assume that the widget nib will need to
live at the same point in XUL.framework's directory structure that it would live
in an app's directory structure, the only difference being that frameworks don't
have the top-level Contents directory.  Today, this would be handled in
xulrunner/app/Makefile as it is in the patch for browser, mail, and xpfe, except
xulrunner would root the rsync at macbundle/Contents.  When things change to
build directly into .apps and .frameworks, we'd make the appropriate tweak
depending on the type of bundle being produced.

I'll let Josh say more about his needs with loading the .nib.  I think what the
build system does now bundle hacking, and what I'm proposing here is a lot
cleaner and more flexible.  However, it occurs to me that this may become a
problem in the XULRunner world if you're using the argv[0] main bundle path hack.

Comment 7

[Josh Aas]

The reason I need a nib file in cocoa widgets is becuase of a bug in the menu
bar handling in Mac OS X. If you do not specify a menu bar with a nib (loaded
early-on) in an AppKit-based app, a small menu bar containing only the
Application menu gets created for you. That would be fine, except that any
subsequent calls to [NSApp mainMenu] ignore the Application menu that was
created - you cannot get a reference to it. It cannot be modified, removed,
anything. So - you end up with 1 menu in the menu bar, but when you do [NSApp
mainMenu] you get 0 menus in return. No good. So I load a nib with a main menu
when we launch, then I can access the Application menu and do what I want with
it. The ins-and-outs of this bug are tricky, you really need to mess with it to
understand its evilness. I am not actually using any data in the nib itself,
just using it to get a reference to the Application menu.

Comment 8

[Benjamin Smedberg]

So the xulrunner bundle-creator code is going to have to copy this nib into the
application bundle it creates?

Comment 9

[Josh Aas]

Apple has recognized the bug that necessitates this patch, Apple bug ID #4109792 (they duped my bug against that one). They say there is a fix in the works, still pressing them for a workaround...

Comment 10

[Josh Aas]

Comment on attachment 200266 [details] [diff] [review]
Patch

Looks like we're going to need this. I don't think we're going to find a better solution. I tried a couple more things, and they are really, really scary and don't work anyway.

+# this syntax allows the rule to succeed if the directory is missing,
+# but fail the rsync fails.

I think you're missing an "if" here.

Comment 11

[Josh Aas]

Attachment: updated to tip

This is just an updated version of mark's patch so that it applies to the current trunk.

Mark - this isn't actually copying the nib file for me. I put it in a few places so it would get copied but none worked. Where am I supposed to be putting it?

Comment 12

[Mark Mentovai]

Are you editing the Makefile in the directory you want to copy from, along the lines of comments 1 and 2?

Comment 13

[Josh Aas]

Attachment: more fixs (tabs)

This fixes my earlier comment and fixes a tab problem with two of the rules.

Comment 14

[Josh Aas]

Comment on attachment 206968 [details] [diff] [review]
more fixs (tabs)

This patch works well for me now.

Comment 15

[Benjamin Smedberg]

Comment on attachment 206968 [details] [diff] [review]
more fixs (tabs)

I definitely don't want to do this without seeing where it's going to be used, so either with this patch or mark the dependent bug.

Comment 16

[Josh Aas]

(In reply to comment #15)
> (From update of attachment 206968 [details] [diff] [review] [edit])
> I definitely don't want to do this without seeing where it's going to be used,
> so either with this patch or mark the dependent bug.

The bug is 316076. See the patch called "work around application menu blessing, v1.0" and also the nib file posted there. See comment #7 in this bug for more of an explanation. I've tried a lot of workarounds and I can't get it going without doing this. Apple has admitted that this is a known issue and they have no better solution.

Comment 17

[Benjamin Smedberg]

ok, track the multi-bug discussion at bug 316076 comment 25

Comment 18

[Josh Aas]

Mark, Benjamin - this is unnecessary now, right? We can probably close this out.

Comment 19

[Mark Mentovai]

WONTFIX in light of the approach taken by bug 316076.