You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remove requirement for full VS install to build #1940
- 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?
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.
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.
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.
Activity
vors commentedon Aug 19, 2016
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:
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.
kilasuit commentedon Aug 19, 2016
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.
kilasuit commentedon Aug 19, 2016
also I think I have most of this nearly ready but I'm testing it on new builds to make sure
mirichmo commentedon Aug 19, 2016
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.
kilasuit commentedon Oct 3, 2018
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
iSazonov commentedon Oct 4, 2018
I think it was resolved in #7892 /cc Aditya Patwardhan (@adityapatwardhan)
SteveL-MSFT commentedon Oct 4, 2018
I don't believe this is an issue anymore for most contributors as long as one doesn't touch the native code for Windows.