Enable building our repo's without requiring Visual Studio installed #64
Comments
|
For (1) I think we have it mostly worked out. The Roslyn repository has managed to do this and I think we cover the majority of the managed build scenarios. If there is anything that we've missed I think we should call that out here and see what needs to be done. For (2) I know this is something the C++ team is experimenting with. Paddy is the contact. Think they'd be eager to help us out here. |
|
What about Unix? clang, cmake and other random Unix tools and libraries that we need. |
|
I do not see the answer in these PRs. Do you think you can get to a place where I can walk to a random recent Linux and get predictable build on it? I doubt it. And if I need a container to get a 100% predictable build on Linux, why not make it same way on Windows? We use containers today to deal with native dependencies. For example, to build .NET Core for Linux same way as build lab, I get a container that has the right stuff in it. I think this work pretty well. I have used it myself a few times. |
|
The goal (in fact requirement...see bottom of https://github.com/dotnet/arcade/blob/master/Documentation/Overview.md) is to 'clone' and then 'build' with no prereqs. The PR's I pointed you too represents the current thinking on the "how". I like containers too, and today we're not (yet) taking a hard dependency on them for bootstrapping. Do you know if containers on Windows and Mac have "grown up" sufficiently that such a hard dependency is now reasonable to take? |
I think it is a good goal to have for pure managed projects. I agree that you can achieve it for Windows because of we (Microsoft) own the Windows tooling. But I am not sure whether I will want to use it as a developer or contributor on Windows for day-to-day work. These things (Windows SDKs, etc.) are huge (gigabytes). If the build lab wants to download the tooling so be it. But please do not download gigabytes of stuff for me by default when I have them in my Visual Studio installation already. Maybe not the exact version, but that's fine. For Linux, it would be a ton of work to repackage all native dependencies and make them work. Expensive, but doable in theory. The main problem is that it would turn it completely foreign environment, and ports would be close to impossible for community to achive. Do you know about any other open source project that deals with native dependencies by repackaging them? For OSX, I do not think that this goal is ever achievable. I doubt that you will be ever able to legally redist XCode.
I do not know. I think it would be better to wait for them to "grow up" if necessary, rather than reinvent the wheel. |
|
thanks @jkotas. Moving this to where the active discussion is on this right now. |
|
Moving out beyond preview |
|
Signing: #1000 |
|
+1 for this issue System.Commandline cannot adapt Arcade since we expect many non Microsoft contributor. |
|
Any update regarding 2? |
|
I think this is something we still might be interested in, but since we're moving away from native tools bootstrapping, it will have to be considered as part of a different epic. Kicking back to triage. |
…a..46dfaa92 46dfaa92 xunit/xunit#2773: Add Assert.RaisesAny and Assert.RaisesAnyAsync non-generic for EventArgs c0485bdd Add additional NETSTANDARD excludeions for System.AppDomain usage b6cb339c xunit/xunit#2767: Verify types match when comparing FileSystemInfo values 03b07513 Use AppDomain.CurrentDomain.GetAssemblies() to find System.IO.FileSystemInfo type 482be8e0 xunit/xunit#2767: Special case FileSystemInfo objects by just comparing the FullName in Assert.Equivalent 78d70dec xunit/xunit#2767: Prevent stack overflow in Assert.Equivalent with a max traversal depth of 50 d0a234a5 Delay calling Dispose() on CollectionTracker's inner enumerator, for xunit/xunit#2762 96236a4c Add disable for CS8607 in AssertEqualityComparerAdapter because of nullability inconsistency 6193f9ee Move to explicit DateTime(Offset) handling in Assert.Equivalent (related: xunit/xunit#2758) 20e76223 xunit/xunit#2743: Assert.Equal with HashSet and custom comparer ignores comparer 247c1016 Mark BitArray as safe to multi-enumerate 8926c0fc Wrap AssertEqualityComparer collection logic in !XUNIT_FRAMEWORK for v2 xunit.execution.* 90d59772 xunit/xunit#2755: Assert.Equal regression for dictionaries with collection values 17c7b611 Add nullable annotation to Assert.NotNull<T>(T?) (dotnet#64) 1886f126 xunit/xunit#2741: Ensure all exception factory methods are public git-subtree-dir: src/Microsoft.DotNet.XUnitAssert/src git-subtree-split: 46dfaa9248b7aa4c8c88e5cf6d4a6c84671a93f5
@weshaggard commented on Thu Dec 07 2017
In order to make our builds more reliable and maintainable long term we need to be able to bootstrap our toolsets as part of our build initialization and stop relying on globally installed tools. This includes things like CMake and Visual Studio but for this issue I want to focus on what it would take to break our dependency on requiring Visual Studio. Note that I think we should support using Visual Studio if it is present but we should be able to build without it and allow folks to isolate themselves and build without it even if it is installed.
There are a few things I'm aware of that need to be figured out in order to break our VS dependency:
cc @shawnro @dleeapho
The text was updated successfully, but these errors were encountered: