Skip to content

Remove requirement for full VS install to build #1940

Closed

Description

@kilasuit

As mentioned in issue #1715 there are some talks with removing the need for Start-PSBuild to be reliant of VS to be installed.

This isn't an easy change to make but would remove a pretty big dependency so for me would be a big win

Issues to overcome

  • - Check for git install in Start-PSBootstrap (required as this isn't already checked
  • - Check for the C ++ tools are installed in Start-PSBootstrap (see Start-PSBuild failing on Windows #1715 for the possible way to get this)
  • - If git is not installed - Install Git in Start-PSBootStrap
  • - If c++ tools are not installed - Register-PackageSource for C ++ tools that are required from Nuget feed as mentioned in Start-PSBuild failing on Windows #1715
  • - If c++ tools are not installed - Install-Package for C ++ tools that are required from Nuget feed as mentioned in Start-PSBuild failing on Windows #1715
  • - If c++ tools are not installed - After install Remove-PackageSource as not required after this
  • - Update Start-PSBuild if required with new locations to check

I think that captures what would be needed to remove the dependency on VS being installed
Keith Hill (@rkeithhill) can you see any other tasks that may be needed?

Activity

  1. vors commented on Aug 19, 2016

    @vors
    Collaborator

    Mike Richmond (@mirichmo) wrote most of the build logic for native things on windows. Mike, what do you think about this proposition?

    As far as I know, we need two parts for native compilation on windows:

    • VS C++ compiler itself + headers.
    • win 10 SDK with lib for the linker.

    I think the first one could be downloaded as a nuget package.

    I definitely support desire to have "fewer dependencies". Meanwhile, I also think that full VS provides a very good dev experience on windows (compare to VS code in it's current state) and likely would be used by most developers anyway.

  2. kilasuit commented on Aug 19, 2016

    @kilasuit
    CollaboratorAuthor

    I'm going through a "machine restructure" at home and have decided that for any PowerShell development I want to be able to build out a brand new win10 dev VM every Friday (obviously scripted using the Lability module & DSC) so that I dont have any reliance on my hardware and could throw it all in Azure at a later stage too.

    Also I'm not a traditional dev so this is really the first jump for me into that world and if I can not rely on VS then I can move to Ubuntu / Mac for other dev work if it works for me.

    So it may be a weird combo of reasons but it would be a good learning curve that I intend to blog about as well. Hopefully that helps you understand my rational behind this suggestion.

  3. kilasuit commented on Aug 19, 2016

    @kilasuit
    CollaboratorAuthor

    also I think I have most of this nearly ready but I'm testing it on new builds to make sure

  4. mirichmo commented on Aug 19, 2016

    @mirichmo
    Member

    sergei (@vors) #1440 removed the Win 10 SDK requirement, so that simplified things a bit.

    Ryan Yates (@kilasuit) Can you clarify your intentions here? Are you experimenting with building all components that we currently build (native + managed) without installing VS? If you just care about building the managed components, then you would just need to modify build.psm1 with a "-BuildManagedOnly" parameter to carve out the native dependencies.

    Assuming that you want to build everything (native and managed), I think simplifying the dependencies is a good thing if we can do it and still meet the existing requirements.

    On Windows platforms for CoreCLR, the goal is to build a single WinRM plugin binary (pwrshplugin.dll) that works across all supported flavors of Windows (7, 8, 8.1, 10, Nano Server, and IoT). The easiest way to meet this requirement is to build it the same way CoreCLR builds native DLLs using the same dependencies. Additionally, the PowerShell project must also produce native powershell.exe and pwrshplugin.dll binaries for FullCLR to ensure backward compatibility with Windows PowerShell.

    Start-PSBuild and Start-PSBootStrap test for the union of these two requirements to ensure that it can build the binaries appropriately. Any change to those cmdlets should take that need into consideration.

    Alternately, if there is strong community desire to streamline the build process and do a managed-only build of PowerShell Core (everything except pwrshplugin.dll), that would be another change to build.psm1 that could be interesting.

  5. added this to the milestone on Sep 29, 2016
  6. modified the milestones: 6.0.0-beta1, , on Mar 13, 2017
  7. modified the milestones: , on May 15, 2017
  8. removed this from the milestone on May 24, 2017
  9. kilasuit commented on Oct 3, 2018

    @kilasuit
    CollaboratorAuthor

    This is now a very old issue and I'm not sure this is relevant still

    Joey Aiello (@joeyaiello) Steve Lee (@SteveL-MSFT) can either of you confirm/deny if this needs revisiting now

  10. iSazonov commented on Oct 4, 2018

    @iSazonov
    Collaborator

    I think it was resolved in #7892 /cc Aditya Patwardhan (@adityapatwardhan)

  11. SteveL-MSFT commented on Oct 4, 2018

    @SteveL-MSFT
    Member

    I don't believe this is an issue anymore for most contributors as long as one doesn't touch the native code for Windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions