Closed Bug 406441 Opened 17 years ago Closed 16 years ago

make it possible to build lightning as universal package

Categories

(Calendar :: Build Config, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mvl, Assigned: mvl)

Details

Attachments

(5 files, 1 obsolete file)

It should be possible to make lightning be an universal build for macosx (i368 and ppc)
This patch should do it. It still needs some magic string in mozconfig to actually use it, but I can now build an universal lightning.
It works by parsing the install.rdf file for the platform. Then it put the .dylib files in the right platform specific directories. After that, it creates one install.rdf file with both platforms as targetPlatform.
I used python for the install.rdf parsing, because it's so easy to parse xml. I tried shell scripts, but that failed.

The scripts are nice and generic in some places (like the install.rdf stuff), and horribly hard-coded in others (the .dylib copying). It might need some cleanup, but I wanted to post what I have.
Assignee: nobody → mvl
Status: NEW → ASSIGNED
Attachment #291093 - Flags: review?
Attachment #291093 - Flags: review? → review?(ause)
Comment on attachment 291093 [details] [diff] [review]
patch v1 [checked in]

hmm, the license block in get-platform.py got lost. Just imagine it is there.
However a solution looks like, it's definitely appreciated for 0.8.
Flags: wanted-calendar0.8+
Attachment #291093 - Flags: review?(mark)
Comment on attachment 291093 [details] [diff] [review]
patch v1 [checked in]

> +DEFINES += -DUNIVERSAL_BINARY=$(UNIVERSAL_BINARY)

Do you use this anywhere?  If not, get rid of it.  There usually isn't any reason for the code to know whether it's going to wind up in a universal binary at compile time.  If you need to know at runtime, we do have something available in nsMacUtils.
Attachment #291093 - Flags: review?(mark) → review+
Attached file my mozconfig
I use this mozconfig for building. The important lines:

. $topsrcdir/calendar/sunbird/config/mozconfig
. $topsrcdir/build/macosx/universal/mozconfig
mk_add_options MOZ_POSTFLIGHT_ALL=calendar/lightning/build/universal.mk
ac_add_app_options ppc --enable-prebinding
Comment on attachment 291093 [details] [diff] [review]
patch v1 [checked in]

patch checked in. Tinderboxes are not yet configured for universal builds.
Attachment #291093 - Attachment description: patch v1 → patch v1 [checked in]
Attachment #291093 - Flags: review?(ause)
mvl, if you're on the trunk, there's no sense in enabling prebinding for ppc, see bug 407399.
mvl, any progress on this? It would be really useful for the next release...
Target Milestone: --- → 0.8
Version: Trunk → unspecified
We should really get this fixed for 0.8 since this would improve our Mac story a lot and makes releasing Lightning much easier.
Flags: wanted-calendar0.8+ → blocking-calendar0.8+
Patch to change the trunk tinderbox to create universal lightning.
Attachment #296807 - Flags: review?(ause)
Comment on attachment 296807 [details] [diff] [review]
tinderbox concfig change, trunk

see the comment on prebinding.

i think at this point we have to give it a try. please commit
Attachment #296807 - Flags: review?(ause) → review+
Patch didn't work out.  I backed out these changes (mvl asked me to if it didn't work):

cvs update -j1.10 -j1.9 mozilla/tools/tinderbox-configs/lightning/macosx/mozconfig
cvs update -j1.5 -j1.4 mozilla/tools/tinderbox-configs/lightning/macosx/CLOBBER
cvs update -j1.9 -j1.8 mozilla/tools/tinderbox-configs/lightning/macosx/mozconfig

Backed out and clobbered build at Jan 14, 2008 23:15 UTC
First error was:
/usr/bin/make -C lightning-obj/ppc/mail/installer \
          UNIVERSAL_BINARY= SIGN_NSS= PKG_SKIP_STRIP=1 stage-package
Makefile:96: *** you need a "--enable-static --disable-shared" build to create an installer.  Stop.

Tried to fix that by not appending to MOZ_POSTFLIGHT_ALL, but overwrite it, so no thunderbird installer will be made. There is no need for it anyway.

Then the next error came up:
mozilla/build/autoconf/mozconfig2client-mk: line 6: /builds/tinderbox/Lightning-Trunk/Darwin_8.8.1_Depend/mozilla/build/macosx/universal/mozconfig: No such file or directory
Not sure how to fix that. Somehow that mozconfig file doesn't exist anymore , while it did before. Might have something to do with that build being a release build, instead of a normal build. Not sure yet how to fix.
regarding the missing /builds/tinderbox/Lightning-Trunk/Darwin_8.8.1_Depend/mozilla/build/macosx/universal/mozconfig, setting 

$MacUniversalBinary = 1

in tinder-config.pl could help. looks like it triggers (beside other things) a "pre-checkout" of the missing file (see build-seamonkey-util.pl line 1066)
Daniel, what do you think about switching the lightning tinderbox to --enable-static? Should that work now on trunk and on branch? It would solve the errors with creating an installer in a much better way. I'm afraid that my first solution will lead to problems at upload, due to missing files and all that.
Is Bug 330753 still present? I can't test it myself currently. If yes --enable-static is no solution.
Regarding bug 330753: Our Sun-internal build jobs build a static thunderbird for lightning and IIRC I've tested a static sunbird for bug 400949, i.e. build both lightning and a static sunbird (trunk+branch) and that lightning worked well.

So yes mvl, I think we should give that a try and --enable-static.
Sounds good. After enabling --enable-static it should be tested is if such a Lightning build works with the official Thunderbird build from a different tinderbox.
new patch, with the MAcUniversalBinary change and the switch to static.
Attachment #297721 - Flags: review?(ause)
Attached patch fixed patchSplinter Review
ehm, I missed a few lines in the last patch. This one got them all.
Attachment #297721 - Attachment is obsolete: true
Attachment #297740 - Flags: review?(ause)
Attachment #297721 - Flags: review?(ause)
Attachment #297740 - Attachment is patch: true
Attachment #297740 - Attachment mime type: application/octet-stream → text/plain
Attachment #297740 - Flags: review?(ause) → review+
I checked in this patch for bustage fix. One problem was with the automatic install of lightning. I disabled that for now. The other problem was with the python script not having the executable bit set. I worked around that by prepending $(PYTHON) to the command line.
The latest changes worked on trunk!  Way to go Michiel, Ause!!!!
mvl, ause, I saw a branch checkin for this bug. Is this bug now FIXED?
not yet. the branch tindoerbox changes haven't see a build yet
looks like PYTHON variable isn't set on branch builds (configure problem?). so i hacked the following three lines into mozilla/calendar/lightning/build/universal.mk to get the tinderboxes green again...

ifeq ($(PYTHON),)
PYTHON=python
endif

@mvl: it's kind of dirty. maybe you have a better idea...
PYTHON ?= python

should be equivalent to your three lines.
i checked exactly that in my previous commit but it didn't work. maybe because actually PYTHON is set in config/autoconf.mk but to empty.
Two issues from looking at the files in <http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-mozilla1.8/mac-xpi/>:

The packaged install.rdf in lightning.xpi lists only em:targetPlatform Darwin_x86-gcc3. Therefore the xpi will not install on Darwin_ppc-gcc3 anymore.

lightning-wcap.xpi is not updated and doesn't contain universal binaries.
Correction on Comment #28: both targetPlatform entries are available in install.rdf but on a single line causing me to miss it when looking at the file.
Is this fixed now? If not, what issues are outstanding?
It's not totally fixes yet: there are no universal lightning-wcap.xpi packages. There are two ways to fix that: make them universal, or make the xpi obsolete. This bug is waiting on a decision on which way to go.
We've talked about that last week and the decision is to make it obsolete, setting the calendar.prototypes.wcap pref. The prototype event dialog had been a major differentiator, but now only few things are left
- WCAP option is visible in calendar creation wizard
- Iff user has a preconfigured WCAP account, the prototype invitation link is available.
How does this affect the following two bugs?:
Bug 349870 – Build Thunderbird with preinstalled Lightning

and:
Bug 401779 – Ship Thunderbird with integrated Lightning 
(In reply to comment #33)
> How does this affect the following two bugs?:
> Bug 349870 and Bug 401779

It does not affect those bugs at all.
The "additional changes" patch comments out the fix for bug 349870. Might be a temporary workaround though.

(In reply to comment #21)
> Created an attachment (id=297853) [details]
> additional changes
> 
> I checked in this patch for bustage fix. One problem was with the automatic
> install of lightning. I disabled that for now.
I've removed the lightning-wcap stuff (bug 415081), so this bug is probably resolved now, right?
With the removal of lightning-wcap, this is now fixed.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
With 20080212 branch Thunderbird and 20080212 branch Lightning builds (Mac 10.5), on my Intel Mac fresh profile, Lightning installed successfully.

Verifying.
Status: RESOLVED → VERIFIED
mvl: is it ok to make the INSTALL_LIGHTNING ifdef go away now and just have that be the default in the non-sunbird case?  Or are there still other things that need to be fixed in order for that to work?
I now see that I didn't copy the error text. But when installing lightning by default, the universal build would fail. I need to re-try it to find the error. I'm not aware of any fixes that would change the situation.
You need to log in before you can comment on or make changes to this bug.