1262567 - Port Bug 1186060 - Build with Visual Studio 2015

Status: RESOLVED FIXED

(Thunderbird :: Build Config, defect)

Comment 1

[aleth [:aleth]]

Attachment: Port Bug 1186060 - Build with Visual Studio 2015

Comment 2

[aleth [:aleth]]

The tooltool-manifest changes already landed.

Comment 3

[Patrick Cloke [:clokep]]

Comment on attachment 8738671 [details] [diff] [review]
Port Bug 1186060 - Build with Visual Studio 2015

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

Let's give this a try...

Comment 4

[aleth [:aleth]]

https://hg.mozilla.org/comm-central/rev/a75a86ce22a938218b3b0397808bc8d7ca0a692a
Bug 1262567 - Port Bug 1186060 - Build with Visual Studio 2015. r=clokep a=aleth CLOSED TREE bustage fix

Comment 5

[aleth [:aleth]]

The builds now fail when trying to pull the vs2015.zip from tooltool:

 INFO - unzipping "vs2015u1.zip"

 WARNING: Timeout (300) exceeded, killing process 3984

 retry: Calling <function run_with_timeout at 0x027FAC30> with args: (['python.exe', 'c:/mozilla-build/tooltool.py', '--authentication-file', 'c:\\builds\\relengapi.tok', '--url', 'https://api.pub.build.mozilla.org/tooltool/', '--overwrite', '-m', 'mail/config/tooltool-manifests/win32/releng.manifest', 'fetch'], 300, None, None, False, True), kwargs: {}, attempt #2

https://treeherder.mozilla.org/logviewer.html#?job_id=35545&repo=comm-central#L1673

gps suggested this might be because c-c doesn't yet have access to the internal tooltool repo.

Comment 6

[aleth [:aleth]]

Oh wait, the download seems to work on the second attempt. https://treeherder.mozilla.org/logviewer.html#?job_id=35545&repo=comm-central#L1681

What's VS2010 doing here?
https://treeherder.mozilla.org/logviewer.html#?job_id=35545&repo=comm-central#L2001

Then, the configure failure
https://treeherder.mozilla.org/logviewer.html#?job_id=35545&repo=comm-central#L2092

Comment 7

[aleth [:aleth]]

(In reply to aleth [:aleth] from comment #6)
> What's VS2010 doing here?
> https://treeherder.mozilla.org/logviewer.html#?job_id=35545&repo=comm-
> central#L2001

Looks like these also show up on successful m-c builds.

Comment 8

[aleth [:aleth]]

(In reply to aleth [:aleth] from comment #6)
> Then, the configure failure
> https://treeherder.mozilla.org/logviewer.html#?job_id=35545&repo=comm-
> central#L2092

Probably some LIB or LIBPATH path issue.

Comment 9

[Justin Wood (:Callek)]

(In reply to aleth [:aleth] from comment #5)
> The builds now fail when trying to pull the vs2015.zip from tooltool:
> 
>  INFO - unzipping "vs2015u1.zip"
> 
>  WARNING: Timeout (300) exceeded, killing process 3984
> 
>  retry: Calling <function run_with_timeout at 0x027FAC30> with args:
> (['python.exe', 'c:/mozilla-build/tooltool.py', '--authentication-file',
> 'c:\\builds\\relengapi.tok', '--url',
> 'https://api.pub.build.mozilla.org/tooltool/', '--overwrite', '-m',
> 'mail/config/tooltool-manifests/win32/releng.manifest', 'fetch'], 300, None,
> None, False, True), kwargs: {}, attempt #2
> 
> https://treeherder.mozilla.org/logviewer.html#?job_id=35545&repo=comm-
> central#L1673
> 
> gps suggested this might be because c-c doesn't yet have access to the
> internal tooltool repo.

I actually suspect we got the tooltool file just fine (and timed out with some slow network and not due to access)....

Also note we probably want:

https://dxr.mozilla.org/comm-central/source/mozilla/build/unix/mozconfig.gtk#5

ported here, TOOLTOOL_DIR instead of *just* topsrcdir, the idea being that topsrcdir is not === to the same abspath in c-c and in m-c. So with that as stands we're looking in the *correct* place for VS2015 for c-c and the incorrect place in mozilla's paths.

This however, would need a change in the m-c tree as well as the c-c tree though.

Comment 10

[aleth [:aleth]]

(In reply to Justin Wood (:Callek) [back on Mar 21] from comment #9)
> I actually suspect we got the tooltool file just fine (and timed out with
> some slow network and not due to access)....

Yes, that was a false alarm, see comment 6.

> Also note we probably want:
> 
> https://dxr.mozilla.org/comm-central/source/mozilla/build/unix/mozconfig.
> gtk#5
> 
> ported here, TOOLTOOL_DIR instead of *just* topsrcdir, the idea being that
> topsrcdir is not === to the same abspath in c-c and in m-c.

Ported to where? The places where VSPATH is set?

Comment 11

[Justin Wood (:Callek)]

(In reply to aleth [:aleth] from comment #10)
> (In reply to Justin Wood (:Callek) [back on Mar 21] from comment #9)
> > Also note we probably want:
> > 
> > https://dxr.mozilla.org/comm-central/source/mozilla/build/unix/mozconfig.
> > gtk#5
> > 
> > ported here, TOOLTOOL_DIR instead of *just* topsrcdir, the idea being that
> > topsrcdir is not === to the same abspath in c-c and in m-c.
> 
> Ported to where? The places where VSPATH is set?

Yea, inside that block, and doing it the same way, using TOOLTOOL_DIR if set, if not using topsrcdir, and then setting VSPATH based on TOOLTOOL_DIR instead of topsrcdir

Comment 12

[aleth [:aleth]]

Attachment: Use TOOLTOOL_DIR to set VSPATH [c-c]

That merged repo can't come soon enough ;)

Comment 13

[Justin Wood (:Callek)]

Comment on attachment 8739026 [details] [diff] [review]
Use TOOLTOOL_DIR to set VSPATH [c-c]

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

r+ but the real rub is this same patch needs to be applied (and landed) on m-* first, since thats where the largest pain is coming from. We do need it on our end to match, but its not the largest problem.

You'll need a m-* build peer to review it for that side though.

::: build/win32/mozconfig.vs2015-win64
@@ +1,2 @@
>  if [ -z "${VSPATH}" ]; then
> +	TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}

nit, use spaces not tab

::: build/win64/mozconfig.vs2015
@@ +1,2 @@
>  if [ -z "${VSPATH}" ]; then
> +	TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}

same

Comment 14

[aleth [:aleth]]

(In reply to Justin Wood (:Callek) [back on Mar 21] from comment #13)
> r+ but the real rub is this same patch needs to be applied (and landed) on
> m-* first, since thats where the largest pain is coming from. We do need it
> on our end to match, but its not the largest problem.

This is already patch for m-*, I assumed you were a m-* build peer. I'll redirect the review.

Comment 15

[aleth [:aleth]]

Attachment: Use TOOLTOOL_DIR to set VSPATH [m-c]

Comment 16

[aleth [:aleth]]

Looks good on try.

Comment 17

[aleth [:aleth]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a60d4b9232b19fb0d9726bdc2376fe4924dee9fc
Bug 1262567 - Use TOOLTOOL_DIR to set VSPATH. r=glandium

Comment 18

[aleth [:aleth]]

https://hg.mozilla.org/comm-central/rev/3dc29f637ced75148a51e7775bb3ad16bbdd687f
Bug 1262567 - Use TOOLTOOL_DIR to set VSPATH. r=Callek a=bustage-fix CLOSED TREE

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a60d4b9232b1