search

dotnet / arcade

Tools that provide common build infrastructure for multiple .NET Foundation projects.
MIT License
665 stars 341 forks source link

Enable building our repo's without requiring Visual Studio installed #64

Open markwilkie opened 6 years ago

markwilkie commented 6 years ago

@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: 1) We need msbuild along with the managed tools and targets.

cc @shawnro @dleeapho

jaredpar commented 6 years ago

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.

jkotas commented 6 years ago

What about Unix? clang, cmake and other random Unix tools and libraries that we need.

markwilkie commented 6 years ago

@jkotas - to PR's in flight for this: https://github.com/dotnet/arcade/pull/131 https://github.com/dotnet/arcade/pull/129

jkotas commented 6 years ago

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.

markwilkie commented 6 years ago

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?

jkotas commented 6 years ago

clone' and then 'build' with no prereqs

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.

you know if containers on Windows and Mac have "grown up"

I do not know. I think it would be better to wait for them to "grow up" if necessary, rather than reinvent the wheel.

markwilkie commented 6 years ago

thanks @jkotas. Moving this to where the active discussion is on this right now.

markwilkie commented 5 years ago

Moving out beyond preview

tmat commented 5 years ago

Signing: https://github.com/dotnet/arcade/issues/1000

wli3 commented 5 years ago

+1 for this issue System.Commandline cannot adapt Arcade since we expect many non Microsoft contributor.

ViktorHofer commented 5 years ago

Any update regarding 2?

jonfortescue commented 2 years ago

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.