Is there any interest upstream in a Windows Mingw Toolchain to build v8?

56 views
Skip to first unread message

Rodrigo Hernandez

unread,
Oct 27, 2020, 12:31:41 PM10/27/20
to v8-dev
Hello,

Early this year I took on the task to make v8 build using msys2 mingw,
between July and August I was successful in doing so, I submitted a patchset
and build script to the msys-mingw project and now there is an official mingw-w64 v8 package for 32 bit as well as 64 bit.

You can see the patches required here:


So, in order to reduce the size of the patches (or remove them altogether), I was wondering whether this is something v8 developers would be interested in so it can be merged upstream.

Thanks!

Jakob Kummerow

unread,
Oct 27, 2020, 2:41:30 PM10/27/20
to v8-dev
Historically, we've been fine with accepting (reasonably non-intrusive) patches to fix/improve MinGW support. Note that this does not mean that we would officially support/maintain/test that configuration; we would continue to rely on community support (i.e. people like you) to notice and fix any breakage.

Also, note that the build/ directory is DEPS'ed in, i.e. you would have to submit those changes to Chromium rather than V8. I don't know how the Chromium project thinks about MinGW these days.


--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/f620d142-e08e-4d9e-bb18-8003b0f88452n%40googlegroups.com.

Rodrigo Hernandez

unread,
Oct 27, 2020, 4:35:58 PM10/27/20
to v8-dev
Thank you Jakob,

I am fine with that, it is not my intention to do a code drop and forget about it, my intention is to keep the configuration valid for as long as I can within my own constraints.

I am also aware that the build directory belongs to the overarching chromium project, unfortunately most of the changes belong in there, these patches add a new toolchain after all.
in particular I am adding a is_mingw gn variable similar to the is_clang variable which is frowned upon from what I can gather.

Anyway, just wanted to know if there is any possible animosity towards the changes before working on a code review and have it shut down right away.

Thanks Again.

Tekman

unread,
Oct 27, 2020, 4:46:41 PM10/27/20
to v8-dev
What about working on a more official MSVC build support? There are other projects (like node.js) building with MSVC, but since Chromium dropped that support, V8's build often needs patching and feels like it's on its last legs.

The good news is that as of 8.6 (and with a few patches we can backport from node) we can actually build all Windows platforms / architectures / flavors, so it would be easier to build vcpkg portfiles or whatever else on top of that existing support (of course, having a few build bots / CI configs testing the config doesn't break would be marvelous).



Rodrigo Hernandez

unread,
Oct 27, 2020, 10:34:54 PM10/27/20
to v8-dev

Hi Tekman,

Yes, that's part of it as well, I added a vcpkg port for 8.3 too but now I tried to update to 8.5 and the PR won't merge because with the mingw side of things the patches become too big for the vcpkg repo 🤷‍♀️
Full story: https://github.com/microsoft/vcpkg/pull/13355

I need mingw because that's what I like and what I use to develop, I want vcpkg because I keep my projects in sync mingw/msvc/linux. I can't link to the MSVC libs from mingw because of the ABI, so I guess if push comes to shove,
I could do with a personal vcpkg fork, but that's not my ideal.
Reply all
Reply to author
Forward
0 new messages