Port Bug 1186060 - Build with Visual Studio 2015

RESOLVED FIXED in Thunderbird 48.0

Status

Thunderbird
Build Config
--
blocker
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: aleth, Assigned: aleth)

Tracking

48 Branch
Thunderbird 48.0
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Comment hidden (empty)
(Assignee)

Updated

2 years ago
Blocks: 1262561
(Assignee)

Comment 1

2 years ago
Created attachment 8738671 [details] [diff] [review]
Port Bug 1186060 - Build with Visual Studio 2015
Attachment #8738671 - Flags: review?(clokep)
(Assignee)

Updated

2 years ago
Assignee: nobody → aleth
Status: NEW → ASSIGNED
(Assignee)

Updated

2 years ago
Severity: normal → blocker
(Assignee)

Comment 2

2 years ago
The tooltool-manifest changes already landed.
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...
Attachment #8738671 - Flags: review?(clokep) → review+
(Assignee)

Comment 4

2 years ago
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
(Assignee)

Updated

2 years ago
Blocks: 1186060
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 48.0
(Assignee)

Comment 5

2 years ago
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.
Status: RESOLVED → REOPENED
Flags: needinfo?(bugspam.Callek)
Resolution: FIXED → ---
(Assignee)

Comment 7

2 years ago
(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.
(Assignee)

Comment 8

2 years ago
(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.
(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.
(Assignee)

Comment 10

2 years ago
(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?
Flags: needinfo?(bugspam.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
Flags: needinfo?(bugspam.Callek)
(Assignee)

Comment 12

2 years ago
Created attachment 8739026 [details] [diff] [review]
Use TOOLTOOL_DIR to set VSPATH [c-c]

That merged repo can't come soon enough ;)
Attachment #8739026 - Flags: review?(bugspam.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
Attachment #8739026 - Flags: review?(bugspam.Callek) → review+
(Assignee)

Comment 14

2 years ago
(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.
(Assignee)

Comment 15

2 years ago
Created attachment 8739029 [details] [diff] [review]
Use TOOLTOOL_DIR to set VSPATH [m-c]
Attachment #8739029 - Flags: review?(mh+mozilla)
(Assignee)

Updated

2 years ago
Attachment #8739026 - Attachment description: Use TOOLTOOL_DIR to set VSPATH → Use TOOLTOOL_DIR to set VSPATH [c-c]
(Assignee)

Updated

2 years ago
Attachment #8739029 - Attachment description: Use TOOLTOOL_DIR to set VSPATH → Use TOOLTOOL_DIR to set VSPATH [m-c]
(Assignee)

Comment 16

2 years ago
Looks good on try.
Attachment #8739029 - Flags: review?(mh+mozilla) → review+
(Assignee)

Comment 18

2 years ago
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

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/a60d4b9232b1
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.