1042374 - DOMi, Chatzilla and other XPIs not being generated with current trunk (22nd July 2014)

Status: RESOLVED WORKSFORME

(SeaMonkey :: Build Config, defect)

Description

[Ian Neal]

STR
1/ Pull latest trunk
2/ Build with make -f client.mk
3/ Once completed, look in mozilla/dist/xpi-stage directory

Expected Result
1/ Contains chatzilla, debugQA, gdata-provider, inspector and other XPIs

Actual Result
1/ Contains only quitter and dbgserver XPIs

Note
Fails on aurora following uplift.
Works on c-c (b925b4ff54bd) and m-c (4b66860fde6d) from about 1st July

Comment 1

[Ian Neal]

Using c-c (699551e9deae) and m-c (c3496e9453d3) from about 6th July only produces dgbserver and quitter XPIs (also gdata-provider and lightning from having calendar building enabled)

Comment 2

[Ian Neal]

Using c-c (eaaf1076354f) and m-c (81691a55e60f) from about 4th July does not work correctly either.

Comment 3

[Ian Neal]

Using c-c (d2c28df60dab) and m-c (f8802f568bb4) from about 3rd July does not work correctly.

Comment 4

[Edmund Wong (:ewong)]

(In reply to Ian Neal from comment #0)
> STR
> 1/ Pull latest trunk
> 2/ Build with make -f client.mk
> 3/ Once completed, look in mozilla/dist/xpi-stage directory
> 
> Expected Result
> 1/ Contains chatzilla, debugQA, gdata-provider, inspector and other XPIs
> 
> Actual Result
> 1/ Contains only quitter and dbgserver XPIs
> 

I'm on Vista, MSVC 2010.  I'm not seeing this. I have all the other XPIs
after doing a clobber on an updated c-c (42281e0027ee) /m-c (82df3654cd80) tree.

I'm going to try aurora next.

Comment 5

[Ian Neal]

Works on c-c (b925b4ff54bd) and m-c (38ecfc3922b8).

Comment 6

[Ian Neal]

Attachment: Build log from revs in comment 3

Comment 7

[Ian Neal]

Attachment: Build log from revs in comment 5

Comment 8

[[e-mail]]

<ewong> For some reasons it's configuring ../mail

Fallout from bug 1033958.

Prior to that bug, configure used mozconfig loader to find your .mozconfig, and since the loader knew your topsrcdir (because that's where configure was being run from) it would find your .mozconfig there and load it.

After that bug, configure uses mach to find your .mozconfig, unfortuantely mach doesn't know which configure you're using, so it looks in the only place it knows, which is the dir in which mach is, i.e. the mozilla subdir. Things go downhill from here, since you either have a Firefox mozconfig there (in which case the build system gets confused because it can't find the browser app in comm-central) or no mozconfig at all, in which case it builds stock Thunderbird.

The easy workaround is to set MOZCONFIG before configuring, but of course that's really annoying, since you have to do it once for each objdir.

Once you have an objdir, configure saves the srcdir there, and next time you configure, it will find the .mozconfig in your srcdir, so this problem only arises once per objdir. Indeed, an alternative workaround is to run configure twice, then build. (Note that the first configure will create a useless mail/ subdir in your objdir, you can safely delete this.)

Comment 9

[[e-mail]]

OK, so bug 1040009 is similar (mozconfig not being read), and that blames bug 1035096, so maybe mach can find your srcdir but only if your objdir is a subdir of your srcdir.

Comment 10

[Robert Kaiser]

(In reply to [e-mail] from comment #8)
> The easy workaround is to set MOZCONFIG before configuring, but of course
> that's really annoying, since you have to do it once for each objdir.

Of course, in that case, you run into bug 1036667...

Comment 11

[Ian Neal]

WFM, closing