Closed Bug 486782 Opened 12 years ago Closed 12 years ago
New variable: MOZ
_FS _LAYOUT should be used instead of OS or Toolkit to determine file system layout
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_6; en-us) AppleWebKit/530.5+ (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 Build Identifier: Darwin/gtk uses the traditional UNIX layout, but there are places in the build that assume Darwin = bundle. The cleanest solution is to create a single new variable to describe this that has options for: traditional : The traditional unix layout (placing the startup script in bin, libs, etc in mozilla_five_home, etc) bundle : Create a NextStep / Darwin / OSX style bundle (ie: Firefox.app) winnt : windows stuff (I have no real understanding of how that works, but I assume we'd replace most of the OS=WINNT with this check) Reproducible: Always
Status: UNCONFIRMED → NEW
Component: General → Build Config
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → build-config
Assignee: nobody → jeremyhu
Hardware: PowerPC → All
What should the values of this variable be for OS2 and BeOS?
We would probably *not* replace OS=WINNT with this, since most of the windows checks are for which files to build (OS integration, etc) and not packaging details. I think for now we only need two values, "unix" and "bundle".
Here's a patch to consider. The one thing I'm not too sure about is the transition of -DNO_X11 from HOST_CFLAGS to TK_CFLAGS. I was having some trouble figuring out what HOST and TARGET were for since they seem to be breaking convention that I'm used to (BUILD = host you're building on, HOST = host the code will run on, TARGET = host built apps will generate code for). Therefore, I don't understand why there is anything to do with TARGET in configure.in, and it looks like TARGET is what HOST should be (the platform mozilla will run on) and HOST is what BUILD should be?
Attachment #372025 - Flags: review?(benjamin)
Comment on attachment 372025 [details] [diff] [review] possible patch to add MOZILLA_FS_LAYOUT to configure.in Yeah, our configure uses host|target for build|host due to longstanding (1998) tradition.
Attachment #372025 - Flags: review?(benjamin) → review+
The patch has been bitrotted by several intervening changes (removing the old mac-cairo codepaths, as well as removing all references to FlatCarbon). Also I've reverted the changes for -DNO_X11, because that is specific to HOST_CFLAGS: it's used in config/mkdepend/def.h and I think we can happily state that you don't need X11 to build mkdepend on Darwin, no matter whether you end up targeting darwin-cocoa or x11/gtk.
Attachment #372413 - Flags: review?(jeremyhu)
Comment on attachment 372413 [details] [diff] [review] Updated to trunk, reverted NO_X11 changes, rev. 1 [Checkin: Comment 10] Thanks, that looks good. Is this and the related changes only going to be targeted at trunk? I'd like to get it into 1.9.1 as well, so I can reduce our patchset size.
Attachment #372413 - Flags: review?(jeremyhu) → review+
Although in retrospect, we might want to name it MOZ_FS_LAYOUT instead of MOZILLA_FS_LAYOUT for better naming consistency with the other variables...
This is an updated patch against 1.9.1 which addresses changes your made in your trunk patch and changes the name to MOZ_FS_LAYOUT to match the naming style of similar variables
Attachment #372025 - Attachment is obsolete: true
Summary: New variable: MOZILLA_FS_LAYOUT should be used instead of OS or Toolkit to determine file system layout → New variable: MOZ_FS_LAYOUT should be used instead of OS or Toolkit to determine file system layout
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 372571 [details] [diff] [review] updated 1.9.1 patch You should either request review+approval or obsolete this patch.
Target Milestone: --- → mozilla1.9.2a1
Version: unspecified → Trunk
Attachment #372413 - Attachment description: Updated to trunk, reverted NO_X11 changes, rev. 1 → Updated to trunk, reverted NO_X11 changes, rev. 1 [Checkin: Comment 10]
You need to log in before you can comment on or make changes to this bug.