Open Bug 1259488 Opened 4 years ago Updated 2 years ago
Enable local builds to easily use VS2015 toolchain from tooltool
Bug 1186060 changed our automation configs to run VS2015 from a self-contained zip file uploaded to tooltool containing the VS2015 compiler and all required SDKs. It would be rad if we could easily configure local developer builds to use this "distribution" for building. e.g. --enable-automation-toolchain (or equivalent) would download the appropriate archive from tooltool, decompress it, and modify other environment/configure variables to find things from that archive. Unfortunately, we can't distribute the Microsoft files publicly. So people will need a tooltool auth token with access to the internal server for this to work. But I think it would be a huge benefit to developer productivity if the toolchain was managed automatically and transparently by the build system, so the cost of configuring tooltool access once seems justified.
OTOH... MSVC is very easy to install on its own or with chocolatey... I'm not particularly convinced that installing it from tooltool is very helpful, especially as it's stripped down (btw, did you remove the GUI?)
Yes, we don't bundle the GUI components. The zip is only 330MB. If it were a bzip2, it would be like 110 MB or something like that. Most of the space is in .lib files. This is much more compact than a full VS install, which is several gigabytes. It also takes much less time to get the zip (assuming a decent internet connection) than waiting seemingly forever for the Visual Studio installer to complete.
Maybe so, but you also can't use the tooltool package to request more of the VS, so if you want the GUI, which includes the debugger, which is pretty much indispensable, you need to install with the VS installer anyways. So I'm not at all convinced of the usefulness of a "use the tooltool package" mode, at least for VS.
Convenience? Having the build system e.g. automatically switch between VS2015u1 and VS2015u2 when bisecting is really convenient. Deterministic builds? This could lead to things like increased compiler cache hit rate, especially if there are minor variances such as minor changes in SDK versions. Anyway, I have no intent of actually working on this at this time. I just thought we should have the bug on file.
You need to log in before you can comment on or make changes to this bug.