Closed Bug 173084 Opened 20 years ago Closed 19 years ago
Need separate build config for building xre
Currently if you define MOZ_PHOENIX, you get phoenix + the xre library which stand alone apps need. This makes it hard for other stand alone applications (like mail) to build easily with the XRE. I think we want to split MOZ_PHOENIX into two configurations: 1) MOZ_PHOENIX and 2) MOZ_XRE_APP In order to not require any environment changes for phoenix one could automatically define MOZ_XRE_APP if MOZ_PHOENIX is defined. I'll post some config patches which demonstrate what I'm talking about.
This patch contains the config changes I made on the trunk back when I had minotaur running on the trunk. The patch assumes the following: 1) toolkit\xre is moved to embedding\xre 2) If the user wants to build phoenix, they also need to start defining MOZ_XRE_APP in their config file and environment instead of just MOZ_PHOENIX. 3) If you wanted to build MOZ_MINOTAUR, then you'd need the mozilla\mailnews\app directory I have in my tree as well. You would add the following to your .mozconfig file to build stand alone mail: export MOZ_MINOTAUR=1 export MOZ_XRE_APP=1 export MOZ_EXTENSIONS= mk_add_options MOZ_MINOTAUR=1 mk_add_options MOZ_XRE_APP=1 mk_add_options MOZ_EXTENSIONS= just replace with MOZ_PHOENIX for phoenix.
suresh should be cc'ed on this bug since it probably impacts the XRE working he is looking into.
XRE is still somewhere on my back burner.
Assignee: mscott → sspitzer
Minotaur is getting resurrected again. Here is an updated config patch against the trunk.
Attachment #103249 - Attachment is obsolete: true
Hijacking this bug for the config changes to land minotaur on the trunk.
Assignee: sspitzer → mscott
Here's an explanation of the changes: 1) configure.in --> If MOZ_MINOTAUR is defined, then define MOZ_XUL_APP 2) allmakefiles.sh --> Bryner already landed a change to define MOZ_XUL_APP if MOZ_PHOENIX is defined. Move mozilla/toolkit Makefiles to MAKEFILES_xulapp so they can be shared by all xul apps. Add Makefile declarations for all the directories in mozilla/mail which is the new home of minotaur 3) client.mk --> cvs co of minotaur should pull mozilla/mail and mozilla/toolkit 4) Makefile.in --> if building minotaur, build toolkit/xre and mail. Don't build xpfe/boostrap if MOZ_XUL_APP (this used to be if not MOZ_PHOENIX)
Attachment #115115 - Attachment is obsolete: true
I still need to do a test build of Phoenix to make sure these changes still work with Phoenix.
just to be clear, what exactly is a MOZ_XUL_APP client? :-) is the xpfe/bootstrap client using MOZ_XUL_APP? The reason I ask is that I want to build mozilla without any XUL for very small devices (aka minimo) and am wondering how this define intersects with the defines that I am already using.
Doug, MOZ_XUL_APP means: 1) a stand alone xul application that uses toolkit/xre to be stand alone 2) a xul app built using mozilla/toolkit It is used by common stand alone xul apps such as Minotaur, Phoenix, and any other XUL app that comes along. The xpfe/boostrap client is not built with this define. In otherwords Seamonkey is not built with this define. It sounds like you might want a disable xul or a no xul type define right?
Comment on attachment 119539 [details] [diff] [review] trunk config changes for minotaur >Index: configure.in >=================================================================== >RCS file: /cvsroot/mozilla/configure.in,v >retrieving revision 1.1207 >diff -u -w -r1.1207 configure.in >--- configure.in 4 Apr 2003 21:14:34 -0000 1.1207 >+++ configure.in 5 Apr 2003 06:01:16 -0000 >@@ -3271,6 +3271,19 @@ > AC_SUBST(MOZ_XUL_APP) > > dnl ======================================================== >+dnl = Minotaur >+dnl ======================================================== >+MOZ_XUL_APP= I don't think you want to unset MOZ_XUL_APP here. It may have been set up above in the Phoenix section, and we probably want to support building Phoenix and Minotaur in the same tree (I don't see any reason why not). >+if test "$MOZ_MINOTAUR"; then >+ AC_DEFINE(MOZ_MINOTAUR) >+ MOZ_XUL_APP=1 >+ AC_DEFINE(MOZ_XUL_APP) >+fi >+ >+AC_SUBST(MOZ_MINOTAUR) >+AC_SUBST(MOZ_XUL_APP) Get rid of the previous AC_SUBST(MOZ_XUL_APP) up above in the Phoenix section. >Index: allmakefiles.sh >=================================================================== >RCS file: /cvsroot/mozilla/allmakefiles.sh,v >retrieving revision 1.405 >diff -u -w -r1.405 allmakefiles.sh >--- allmakefiles.sh 4 Apr 2003 21:24:56 -0000 1.405 >+++ allmakefiles.sh 5 Apr 2003 06:01:16 -0000 >@@ -856,6 +856,9 @@ > browser/components/prefwindow/locale/Makefile > browser/components/search/Makefile > browser/components/search/resources/Makefile >+" >+ >+MAKEFILES_xulapp=" > toolkit/Makefile > toolkit/components/autocomplete/Makefile > toolkit/components/autocomplete/public/Makefile >@@ -872,10 +875,16 @@ > " > > MAKEFILES_minotaur=" >-mail/Makefile >+mail/app/Makefile >+mail/app/profile/Makefile > mail/base/Makefile > mail/components/Makefile > mail/components/compose/Makefile >+mail/components/addrbook/Makefile >+mail/components/prefwindow/Makefile >+mail/extensions/Makefile >+mail/extensions/smime/Makefile >+mail/extensions/offline/Makefile > " > > MAKEFILES_sql=" >@@ -1297,6 +1306,10 @@ > > if test -n "$MOZ_PHOENIX"; then > add_makefiles "$MAKEFILES_phoenix" >+fi >+ >+if test -n "$MOZ_XUL_APP"; then >+ add_makefiles "$MAKEFILES_xulapp" > fi > > if test -n "$MOZ_MINOTAUR"; then >Index: client.mk >=================================================================== >RCS file: /cvsroot/mozilla/client.mk,v >retrieving revision 1.189 >diff -u -w -r1.189 client.mk >--- client.mk 11 Dec 2002 07:06:43 -0000 1.189 >+++ client.mk 5 Apr 2003 06:01:16 -0000 >@@ -362,6 +362,19 @@ > endif > > #################################### >+# CVS defines for Minotaur (pulled and built if MOZ_MINOTAUR is set) >+# >+ >+CVSCO_MINOTAUR := $(CVSCO) $(CVS_CO_DATE_FLAGS) mozilla/toolkit mozilla/mail Can we consolidate this so that we have one pull of mozilla/toolkit for both Phoenix and Minotaur? I'd even suggest that we might want to pull it by default. >+#################################### > # CVS defines for codesighs (pulled and built if MOZ_MAPINFO is set) > # > CVSCO_CODESIGHS := $(CVSCO) $(CVS_CO_DATE_FLAGS) mozilla/tools/codesighs >@@ -442,6 +455,7 @@ > cvs_co $(CVSCO_CALENDAR) && \ > $(CHECKOUT_LIBART) && \ > $(CHECKOUT_PHOENIX) && \ >+ $(CHECKOUT_MINOTAUR) && \ All of the other lines here are using a hard tab, please do that for this line. >@@ -502,6 +516,7 @@ > fast_update $(CVSCO_CALENDAR) && \ > $(FASTUPDATE_LIBART) && \ > $(FASTUPDATE_PHOENIX) && \ >+ $(FASTUPDATE_MINOTAUR) && \ Same here. >Index: Makefile.in >=================================================================== >RCS file: /cvsroot/mozilla/Makefile.in,v >retrieving revision 1.213 >diff -u -w -r1.213 Makefile.in >--- Makefile.in 4 Apr 2003 07:28:03 -0000 1.213 >+++ Makefile.in 5 Apr 2003 06:01:16 -0000 >@@ -259,6 +259,13 @@ > > ifdef MOZ_PHOENIX > tier_99_dirs += browser >+endif >+ >+ifdef MOZ_MINOTAUR >+tier_99_dirs += toolkit/xre mail >+endif >+ Let's put toolkit/xre in a section that's conditional on MOZ_XUL_APP. >+ifdef MOZ_XUL_APP > else > ifdef MOZ_XPFE_COMPONENTS > tier_99_dirs += xpfe/bootstrap
Attachment #119539 - Flags: review-
mscott - that is exactly what I added: MOZ_XPFE_COMPONENTS. The meaning is a bit overloaded. Eventually, session history will move out of mozilla/xpfe and I will not have to actually build (still need to export) anything in mozilla/xpfe. Thanks for the clarification.
Bryner, this patch incorporates your review comments with the exception of: >+ifdef MOZ_MINOTAUR >+tier_99_dirs += toolkit/xre mail >+endif >+ You wanted to put toolkit/xre in a MOZ_XUL_APP conditional. I don't think we want to do that. Currently toolkit/xre is included when you build mozilla/toolkit. We explicitly list it here for minotaur because currently minotaur does not build the toolkit directory with the exception of toolkit/xre. Once we move to the new toolkit, this will go away and we'll build toolkit/xre when the toolkit is built. 2) You wanted a single pull of mozilla/toolkit conditional on MOZ_XUL_APP in client.mk. I put that in this patch, but I don't think we really want to do this. If you do it that way, then a user must define MOZ_XUL_APP in their environment for client.mk to see it during the pull. Maybe I was doing something wrong but we were never checking out the toolkit unless I explicitly defined MOZ_XUL_APP in .mozconfig before the tree is pullled. Our implicit setting in configure.in/configure was not enough. Do we want to make minotaur and phoenix users define this variable? (I don't think so). What ifdef should we wrap the change in client.mk in for pulling mozilla toolkit in then? A if phoenix or if minotaur ifdef?
Attachment #119539 - Attachment is obsolete: true
Comment on attachment 120332 [details] [diff] [review] updated patch with bryner's review comments >Index: client.mk >=================================================================== >RCS file: /cvsroot/mozilla/client.mk,v >retrieving revision 1.189 >diff -u -w -r1.189 client.mk >--- client.mk 11 Dec 2002 07:06:43 -0000 1.189 >+++ client.mk 10 Apr 2003 22:20:29 -0000 >@@ -349,9 +349,22 @@ > endif > > #################################### >+# CVS defines for mozilla/toolkit (pulled and built if MOZ_XUL_APP is set) >+# >+ >+CVSCO_MOZTOOLKIT := $(CVSCO) $(CVS_CO_DATE_FLAGS) mozilla/toolkit >+ifdef MOZ_XUL_APP >+FASTUPDATE_MOZTOOLKIT := fast_update $(CVSCO_MOZTOOLKIT) >+CHECKOUT_MOZTOOLKIT := cvs_co $(CVSCO_MOZTOOLKIT) >+else >+FASTUPDATE_MOZTOOLKIT := true >+CHECKOUT_MOZTOOLKIT := true >+endif Sorry, I was pretty vague about this. What I was thinking was, put this _after_ the phoenix and minotaur sections and have those set MOZ_XUL_APP=1 automatically. Sound ok? sr=bryner with that change.
Attachment #120332 - Flags: superreview?(bryner) → superreview+
Updated patch, renaming MOZ_MINOTAUR to MOZ_THUNDERBIRD, added bryner's last comment. will carry over his sr
Attachment #120332 - Attachment is obsolete: true
checked in. but you need Bug #194315 if you are going to actually build thunderbird. That patch is next on my plate.
Assignee: mscott → scott
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.