787982 - Add a wrapper at build/pymake/make.py that pulls in mozilla-central if necessary

Status: RESOLVED FIXED

(MailNews Core :: Build Config, defect)

Description

[Rain [:rain1] (inactive)]

Attachment: patch v1

I've tested this on a Windows builder and it seems to work fine. I'm going to push this to try next.

Comment 1

[Rain [:rain1] (inactive)]

https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=2472163b71e1

Comment 2

[Rain [:rain1] (inactive)]

So one problem with this patch is that since mozilla-central loads up the same .mozconfig, $topsrcdir/build/client.py-args isn't found there. Since mozilla-central doesn't actually use that variable, I don't think this is a big problem. An error does show up in the log, though.

Comment 3

[Rain [:rain1] (inactive)]

Ugh, looks like I'll need to exclude the files from check-sync-dirs.py too.

Comment 4

[Rain [:rain1] (inactive)]

Attachment: patch v2, exclude files from check-sync-dirs

This should be better.

Comment 5

[Rain [:rain1] (inactive)]

Attachment: patch v3, make it dependent on bug 788607

We're going to check this in after enabling pymake on the releng side, so that we have a chance to test Pymake on try.

Comment 6

[Mark Banner (:standard8)]

Comment on attachment 658556 [details] [diff] [review]
patch v3, make it dependent on bug 788607

Review of attachment 658556 [details] [diff] [review]:
-----------------------------------------------------------------

::: build/client.py-args
@@ +1,1 @@
> +--hg-options='--time' --hgtool=../tools/buildfarm/utils/hgtool.py --skip-chatzilla --skip-comm --skip-inspector --skip-venkman --tinderbox-print

I'm not sure this default would work for SeaMonkey when they get to use, as they require pulling the extensions.

However, I think they could still override these args in their mozconfigs, which would then take affect when client.mk calls client.py. Have I got that right?

::: build/pymake/make.py
@@ -1,1 @@
> -#!/usr/bin/env python

Why get rid of this line?

Comment 7

[Rain [:rain1] (inactive)]

(In reply to Mark Banner (:standard8) from comment #6)
> However, I think they could still override these args in their mozconfigs,
> which would then take affect when client.mk calls client.py. Have I got that
> right?

Hmm. Yes, if what is pulled in through these args is a subset of what is pulled in by SM, then it's safe.

> 
> ::: build/pymake/make.py
> @@ -1,1 @@
> > -#!/usr/bin/env python
> 
> Why get rid of this line?

Yeah no reason to. Reinstated locally.

Comment 8

[Mark Banner (:standard8)]

Comment on attachment 658556 [details] [diff] [review]
patch v3, make it dependent on bug 788607

Ok, lets do this.

Comment 9

[Mark Banner (:standard8)]

I just pushed this to try server (compensating for the current bustage on trunk) now that pymake has been enabled for the builders:

https://hg.mozilla.org/try-comm-central/rev/e8e5abab63d0

Comment 10

[Mark Banner (:standard8)]

(In reply to Mark Banner (:standard8) from comment #9)
> I just pushed this to try server (compensating for the current bustage on
> trunk) now that pymake has been enabled for the builders:
> 
> https://hg.mozilla.org/try-comm-central/rev/e8e5abab63d0

Err actually, pymake hasn't been enabled :-( I've re-opened bug 786516.

Comment 11

[Mark Banner (:standard8)]

Re-pushed to try (pymake should be on now): https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=64b8cc05f208

Comment 12

[Mark Banner (:standard8)]

Ok, we have some results, though I don't understand the error:

https://tbpl.mozilla.org/php/getParsedLog.php?id=15821727&tree=Thunderbird-Try
https://tbpl.mozilla.org/php/getParsedLog.php?id=15821676&tree=Thunderbird-Try
https://tbpl.mozilla.org/php/getParsedLog.php?id=15821796&tree=Thunderbird-Try

<msgbase_s.lib.desc>: Found error
<libs>: Found error
e:\builds\moz2_slave\tb-try-c-cen-w32\build\config\rules.mk:998:0$ rm -f msgbsutl_s.lib 
e:\builds\moz2_slave\tb-try-c-cen-w32\build\config\rules.mk:999:0$ c:/mozilla-build/python/python2.6.exe e:/builds/moz2_slave/tb-try-c-cen-w32/build/mozilla/config/pythonpath.py -I../../../mozilla/config e:/builds/moz2_slave/tb-try-c-cen-w32/build/mozilla/config/expandlibs_gen.py --depend .deps/msgbsutl_s.lib.pp -o msgbsutl_s.lib.desc nsMsgLineBuffer.obj nsMsgDBFolder.obj nsMsgKeyArray.obj nsMsgKeySet.obj nsMsgIdentity.obj nsMsgIncomingServer.obj nsMsgUtils.obj nsMsgProtocol.obj nsMsgMailNewsUrl.obj nsMsgTxn.obj nsMsgI18N.obj nsImapMoveCoalescer.obj nsMsgFileStream.obj nsMsgCompressIStream.obj nsMsgCompressOStream.obj nsMsgReadStateTxn.obj nsStopwatch.obj  
e:\builds\moz2_slave\tb-try-c-cen-w32\build\config\rules.mk:745:0: command 'C:/mozilla-build/buildbotve/scripts/python.exe e:/builds/moz2_slave/tb-try-c-cen-w32/build/mozilla/build/pymake/pymake/../make.py -C src libs' failed, return code 2
<libs>: Found error

Comment 13

[Mark Banner (:standard8)]

Found the error, rebuilding currently:

https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=17a0c2af1f2e

Comment 14

[Mark Banner (:standard8)]

Checked in:

https://hg.mozilla.org/comm-central/rev/5a49ea8a7052

Comment 15

[Mark Banner (:standard8)]

Comment on attachment 658556 [details] [diff] [review]
patch v3, make it dependent on bug 788607

[Triage Comment]
We want this on 17 for pymake goodness.

Comment 16

[Mark Banner (:standard8)]

https://hg.mozilla.org/releases/comm-aurora/rev/1bdaadcf21fe

Comment 17

[[e-mail] (:bhearsum)]

Comment on attachment 658556 [details] [diff] [review]
patch v3, make it dependent on bug 788607

Review of attachment 658556 [details] [diff] [review]:
-----------------------------------------------------------------

::: build/client.py-args
@@ +1,1 @@
> +--hg-options='--time' --hgtool=../tools/buildfarm/utils/hgtool.py --skip-chatzilla --skip-comm --skip-inspector --skip-venkman --tinderbox-print

This patch is making us pull the wrong things for releases because we don't have --comm-rev or --mozilla-rev passed to client.py anymore.

Comment 18

[[e-mail] (:bhearsum)]

Turns out I'm wrong - I got totally confused when reading the revision history. This bug doesn't affect the --comm-rev and --mozilla-rev flags at all. We got rid of those in bug 763769 in favour of having client.py look directly at the environment variables instead. There is no problem here after all, yay!