The MSVC bots are gone, MSVC is now community-supported

139 views
Skip to first unread message

Nico Weber

unread,
Apr 16, 2018, 1:51:31 PM4/16/18
to Chromium-dev, blink-dev, cxx
Hi,

as of last Friday, the MSVC bots have been shut down. If you're writing Chromium code, you're no longer responsible for making sure that your code works with MSVC.

We still accept patches for msvc compat from the community, but keeping the MSVC build going is now on people who want to keep using it, and no longer the responsibility of every contributor.

See https://crbug.com/820422 for details, in particular comments 1 and 4.

Nico

Nico Weber

unread,
Apr 16, 2018, 1:57:51 PM4/16/18
to Chromium-dev, blink-dev, cxx
To be clear, we still use the official Windows SDK, and you can still use the Visual Studio IDE like you could before. But we don't have bots that build with Visual Studio's C++ compiler anymore, only the clang-using bots remain.

eng...@chromium.org

unread,
Apr 10, 2019, 5:33:11 AM4/10/19
to cxx, chromi...@chromium.org, blin...@chromium.org, Adam Langley
Nico, what is the status of our MSVC compatibility today? Is support still maintained by the community? More specifically, I was wondering whether actively removing MSVC-specific workarounds we needed in the past (e.g. crrev.com/c/1555063) is encouraged or discouraged.

On Monday, April 16, 2018 at 7:57:00 PM UTC+2, Nico Weber wrote:
To be clear, we still use the official Windows SDK, and you can still use the Visual Studio IDE like you could before. But we don't have bots that build with Visual Studio's C++ compiler anymore, only the clang-using bots remain.

Nico Weber

unread,
Apr 10, 2019, 10:16:41 AM4/10/19
to eng...@chromium.org, cxx, Chromium-dev, blink-dev, Adam Langley
It's the same as when the original email in this thread was written: We don't have bots covering it, we accept patches to keep the build going. I haven't seen anyone contribute patches to keep the build going though, and it likely is broken at the moment. So if something becomes much easier if you remove an MSVC workaround, try removing it and see if anyone shouts :)

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/9c7270e0-7ced-4292-971b-3f3ecae006f8%40chromium.org.

Nico Weber

unread,
Apr 10, 2019, 12:49:46 PM4/10/19
to Adam Langley, eng...@chromium.org, cxx, Chromium-dev, blink-dev
On Wed, Apr 10, 2019 at 12:43 PM Adam Langley <a...@chromium.org> wrote:
On Wed, Apr 10, 2019 at 7:14 AM Nico Weber <tha...@chromium.org> wrote:
It's the same as when the original email in this thread was written: We don't have bots covering it, we accept patches to keep the build going. I haven't seen anyone contribute patches to keep the build going though, and it likely is broken at the moment. So if something becomes much easier if you remove an MSVC workaround, try removing it and see if anyone shouts :)

My experience was that MSVC compatibility was a fair amount of work to keep going. If we're not seeing a steady stream of patches then I don't think that anyone is building with MSVC. But the community-supported stance has costs: it encourages people to worry about MSVC

"Community-supported" is supposed to mean that nobody expect people who want to use this have to worry about it. If anyone reading this worries about MSVC but doesn't build with MSVC: Stop worrying :) MSVC support isn't your problem to worry about.
 
and continue with habitual workarounds that we probably all have after years of tending to it. It also has costs from dealing with the workaround patches, although that cost doesn't appear to exist because of the presumed lack of anyone actually maintaining this.
 
Since we're a week shy of one year I'd suggest that we land a change that triggers a #error for MSVC, give people a month to object, and then potentially move to calling it unsupported. If there are groups building MSVC, and we want to accomodate them, then I think we should actually have bots to maintain it

I disagree with this. If we have supported bots, everyone needs to worry about that build config, instead of just people using it. For example, the gcc build is chugging along fine but only a small number of people need to worry about it since we don't have a bot. I think that's a good setup.
 
—the middle ground seems bad.

But it's not my call, so just my 2 cents here.


Cheers

AGL

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.

Peter Kasting

unread,
Apr 10, 2019, 12:54:24 PM4/10/19
to Nico Weber, Adam Langley, eng...@chromium.org, cxx, Chromium-dev, blink-dev
On Wed, Apr 10, 2019 at 9:47 AM Nico Weber <tha...@chromium.org> wrote:
On Wed, Apr 10, 2019 at 12:43 PM Adam Langley <a...@chromium.org> wrote:
Since we're a week shy of one year I'd suggest that we land a change that triggers a #error for MSVC, give people a month to object, and then potentially move to calling it unsupported. If there are groups building MSVC, and we want to accomodate them, then I think we should actually have bots to maintain it

I disagree with this. If we have supported bots, everyone needs to worry about that build config, instead of just people using it. For example, the gcc build is chugging along fine but only a small number of people need to worry about it since we don't have a bot. I think that's a good setup.

I'm OK with not having bots.  But I think part of Adam's point got missed.  If there really isn't external desire to build with MSVC, knowing that gives us carte blanche to rip out everything MSVC-related that might remain in the codebase.  An explicit #error would be a way to find out whether we can do that.

By comparison, we know people are definitely using GCC builds today, and so while we don't worry about it per se, we also don't rip out GCC-related code.

PK

Nico Weber

unread,
Apr 10, 2019, 2:56:15 PM4/10/19
to Adam Langley, eng...@chromium.org, cxx, Chromium-dev, blink-dev
> I'm OK with not having bots.  But I think part of Adam's point got missed.  If there really isn't external desire to build with MSVC, knowing that gives us carte blanche to rip out everything MSVC-related that might remain in the codebase.  An explicit #error would be a way to find out whether we can do that.

(I'm generally fine with someone doing that. I think Firefox did this.)

On Wed, Apr 10, 2019 at 1:16 PM Adam Langley <a...@chromium.org> wrote:
On Wed, Apr 10, 2019 at 9:47 AM Nico Weber <tha...@chromium.org> wrote:
On Wed, Apr 10, 2019 at 12:43 PM Adam Langley <a...@chromium.org> wrote:
On Wed, Apr 10, 2019 at 7:14 AM Nico Weber <tha...@chromium.org> wrote:
It's the same as when the original email in this thread was written: We don't have bots covering it, we accept patches to keep the build going. I haven't seen anyone contribute patches to keep the build going though, and it likely is broken at the moment. So if something becomes much easier if you remove an MSVC workaround, try removing it and see if anyone shouts :)

My experience was that MSVC compatibility was a fair amount of work to keep going. If we're not seeing a steady stream of patches then I don't think that anyone is building with MSVC. But the community-supported stance has costs: it encourages people to worry about MSVC

"Community-supported" is supposed to mean that nobody expect people who want to use this have to worry about it. If anyone reading this worries about MSVC but doesn't build with MSVC: Stop worrying :) MSVC support isn't your problem to worry about.
 
and continue with habitual workarounds that we probably all have after years of tending to it. It also has costs from dealing with the workaround patches, although that cost doesn't appear to exist because of the presumed lack of anyone actually maintaining this.
 
Since we're a week shy of one year I'd suggest that we land a change that triggers a #error for MSVC, give people a month to object, and then potentially move to calling it unsupported. If there are groups building MSVC, and we want to accomodate them, then I think we should actually have bots to maintain it

I disagree with this. If we have supported bots, everyone needs to worry about that build config, instead of just people using it. For example, the gcc build is chugging along fine but only a small number of people need to worry about it since we don't have a bot. I think that's a good setup.

I think it depends on the gap. My experience is that the Clang–GCC gap is tiny, and thus so are the problems. But the Clang–MSVC gap was pretty big.

It got a bit smaller in VS2017 and it feels like the Visual Studio team started caring about things like compatibility a lot more in the last few years. So if someone were to show up and try to keep that build going, I think it'd be fine to at least see how disruptive it'd be.

But as you say, it's all very hypothetical :) 
 
If people were frequently getting "Fix MSVC build" CLs correcting their changes, I think they would internalise it pretty fast and worry about MSVC, whatever the policy.

But none of this is a problem in practice because, I suspect, the MSVC build is dead. So it's not a big deal unless someone shows up and tries to maintain an MSVC build based on this policy. Thus I recommend burying it while we can :) But it's just a thought; not my area of policy.


Cheers

AGL

Allan Sandfeld Jensen

unread,
Apr 11, 2019, 5:47:29 AM4/11/19
to chromi...@chromium.org, eng...@chromium.org, cxx, blin...@chromium.org, Adam Langley
On Mittwoch, 10. April 2019 11:31:36 CEST eng...@chromium.org wrote:
> Nico, what is the status of our MSVC compatibility today? Is support still
> maintained by the community? More specifically, I was wondering whether
> actively removing MSVC-specific workarounds we needed in the past (e.g.
> crrev.com/c/1555063) is encouraged or discouraged.
>
We are still building Chromium on MSVC in QtWebEngine. I have started
upstreaming the fixes that are due to invalid code in Chromium, but have kept
work-arounds for MSVC local.

Some MSVC-specific workaround was already pulled out in 72 and 73 branches,
that we had to rollback.

Best regards
'Allan Sandfeld Jensen


Reply all
Reply to author
Forward
0 new messages