Add top-level controls to VMR for system libraries #19640
Conversation
Often, when building .NET, we want to build with different configurations of external libraries. For example, runtime has a copy of brotli, and we may or may not want to use that. This introduces top-level properties to the VMR to select whether to use the bundled copy of a library (eg in, runtime/src/native/external) vs the system copy of the library.
| <BuildArgs Condition="'$(UseSystemLibunwind)' != ''">$(BuildArgs) /p:UseSystemLibunwind=$(UseSystemLibunwind)</BuildArgs> | ||
| <BuildArgs Condition="'$(UseSystemLlvmLibunwind)' != ''">$(BuildArgs) /p:UseSystemLlvmLibunwind=$(UseSystemLlvmLibunwind)</BuildArgs> | ||
| <BuildArgs Condition="'$(UseSystemRapidjson)' != ''">$(BuildArgs) /p:UseSystemRapidjson=$(UseSystemRapidjson)</BuildArgs> | ||
| <BuildArgs Condition="'$(UseSystemZlib)' != ''">$(BuildArgs) /p:UseSystemZlib=$(UseSystemZlib)</BuildArgs> |
There was a problem hiding this comment.
Is it better to add specific named options like this? Or better to have generic mechanism to pass any property to the inner build?
There was a problem hiding this comment.
I could imagine an explosion of these over time. It would be better to have some generic passthrough mechanism. @ViktorHofer what do you think?
There was a problem hiding this comment.
Could we use a property named something like UseSystemLibs and have the names specified as a +-deliminated list? Like /p:UseSystemLibs=brotli+libunwind+rapidjson+zlib? And then implement that property as the one that's passed through?
There was a problem hiding this comment.
As part of the installer->sdk repository consolidation we are already switching the VMR over into dotnet/sdk. ETA: today or tomorrow. The last manual code sync happened today and we don't plan on doing another sync. Please close this PR and submit it into dotnet/sdk. Sorry for the inconvenience.
Some environments, at least some Linux distributions, want to use system
versions of certain libraries rather than the source code copy shipped
with the .NET runtime source repository. We can provide a top-level flag
to support this scenario that can be used like this:
./build.sh -p:UseSystemLibs=brotli+libunwind+rapidjson+zlib
Which makes the VMR build the runtime repo such that it uses the system
version of brotli, libunwind, rapidjson and zlib.
This is another attempt at
dotnet/installer#19640
It depends on dotnet/runtime#104440 to work.
Some environments, at least some Linux distributions, want to use system versions of certain libraries rather than the source code copy shipped with the .NET runtime source repository. We can provide a top-level flag to support this scenario that can be used like this:
./build.sh -p:UseSystemLibs=brotli+libunwind+rapidjson+zlib
Which makes the VMR build the runtime repo such that it uses the system version of brotli, libunwind, rapidjson and zlib.
This is another attempt at dotnet/installer#19640
It depends on dotnet/runtime#104440 to work.
Often, when building .NET, we want to build with different configurations of external libraries. For example, runtime has a copy of brotli, and we may or may not want to use that.
This introduces top-level properties to the VMR to select whether to use the bundled copy of a library (eg in, runtime/src/native/external) vs the system copy of the library.
This will be used by dotnet/runtime#101797