460263 - postflight on macosx fails when building thunderbird with preinstalled lightning

Status: VERIFIED FIXED

(Calendar :: Build Config, defect)

Description

[ause]

the unify step breaks because the install.rdf of lightning contain different platform entries.

Comment 1

[ause]

Attachment: merge lightning install.rdf before running unify

Comment 2

[David :Bienvenu]

seems like something we want, since there's a patch - you should request review from a module owner or peer for the module this file is in.

Comment 3

[ause]

Comment on attachment 343385 [details] [diff] [review]
merge lightning install.rdf before running unify

i will come up with another patch as this one will break builds without --enable-calendar

Comment 4

[ause]

Attachment: [checked in] the new version also includes the suggested move of merge-installrdf.py from calendar/lightning/build to build

requires moving merge-installrdf.py in the same commit

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> Created an attachment (id=343537) [details]
> the new version also includes the suggested move of merge-installrdf.py from
> calendar/lightning/build to build
> 
> requires moving merge-installrdf.py in the same commit

Given you're in hg (and with git patches turned on), you can do hg rename yourself to move the file, and then it will show up in hg diff (or hg qdiff if you're using mq as well), you can attach a patch, and if it isn't you pushing it, then as long as the person uses hg import or hg qimport to get it into their repository it will work fine.

Comment 6

[Philippe M. Chiasson (:gozer)]

Is there any way this logic could somehow be kept inside calendar/lightninig/build/*.mk instead of inserting itself into build/* ?

Or possibly better/different, generalize the approach to correctly unify all install.rdf's generated during universal builds (not being lightninig specific), as this is a generic problem with building universal extensions with arch-specific bits.

Comment 7

[ause]

(In reply to comment #6)
> Is there any way this logic could somehow be kept inside
> calendar/lightninig/build/*.mk instead of inserting itself into build/* ?
i don't think that makes sense as the inserted actions are required for tb packing, not for creating a lightning.xpi.

> 
> Or possibly better/different, generalize the approach to correctly unify all
> install.rdf's generated during universal builds (not being lightninig
> specific), as this is a generic problem with building universal extensions with
> arch-specific bits.
sure, the applied patch is just a workaround for the current problem until unify learns how to merge install.rdf. if you like i can try to create for unify. but as this is hosted in another repository and i doubt that we want to duplicate it, this seemed to be the most promising way to get integrated builds for the moment.

Comment 8

[Philippe M. Chiasson (:gozer)]

(In reply to comment #7)
> (In reply to comment #6)
> > Is there any way this logic could somehow be kept inside
> > calendar/lightninig/build/*.mk instead of inserting itself into build/* ?
> i don't think that makes sense as the inserted actions are required for tb
> packing, not for creating a lightning.xpi.

Yes, but what I was trying to say is that it's definitely a workaround for lightning. And under universal builds, any module like lightning would end up requiring this exact same workaround.

> > 
> > Or possibly better/different, generalize the approach to correctly unify all
> > install.rdf's generated during universal builds (not being lightninig
> > specific), as this is a generic problem with building universal extensions with
> > arch-specific bits.
> sure, the applied patch is just a workaround for the current problem until
> unify learns how to merge install.rdf.

Okay, if this was an intended workaround from the start, and teaching unify how to merge install.rdf's, then I am okay with it. r=gozer

Comment 9

[ause]

i submitted Bug 461515 to enhance unify, not sure who to bother with that.

Comment 10

[Martin Schröder [:mschroeder]]

ause: Can this bug be marked FIXED?

Comment 11

[ause]

afaik, preinstalled lightning is still disabled by build configuration. so i'd like to wait until it's active.

Comment 12

[ause]

DISABLE_LIGHTNING_INSTALL is gone now, lightning boxes build thunderbird with preinstalled lightning without error