Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce a UseSystemLibraries option to use the system libunwind #391

Merged
merged 1 commit into from
Apr 4, 2018

Conversation

omajid
Copy link
Member

@omajid omajid commented Apr 2, 2018

See #380. For some examples of why we would want to use the system libraries, see:

UseSystemLibraries lets users control if they want to use the system versions of libraries or bundled libraries. The only use case where this applies currently is coreclr's libunwind.

This PR by itself wont do anything until we pull in a version of coreclr that includes the implementation of CLR_CMAKE_USE_SYSTEM_LIBUNWIND. Currently the option is not understood and just ignored by coreclr's build system.

@@ -4,6 +4,7 @@
<PropertyGroup>
<BuildArguments>$(Platform) $(Configuration) skiptests -PortableBuild=$(PortableBuild)</BuildArguments>
<BuildArguments Condition="'$(OS)' != 'Windows_NT'">$(BuildArguments) msbuildonunsupportedplatform</BuildArguments>
<BuildArguments Condition="'$(UseSystemLibraries)' != 'false'">$(BuildArguments) cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE</BuildArguments>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Normally we do ... == 'true' in MSBuild, is there a reason to take more than true for this arg in particular?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. I just didn't realize the convention.

@dagood
Copy link
Member

dagood commented Apr 3, 2018

@dotnet-bot test this please
#384 brought in a CoreCLR commit with this flag, so rerunning tests on latest.

/cc @dleeapho

UseSystemLibraries lets users control if they want to use the system
versions of libraries or bundled libraries. The only use case where this
applies currently is coreclr's libunwind.
@omajid omajid force-pushed the system-library-libunwind branch from 8edfc91 to 614fa98 Compare April 3, 2018 23:04
@omajid
Copy link
Member Author

omajid commented Apr 4, 2018

@dotnet-bot test this please

@@ -8,6 +8,7 @@
<_IsBootstrapping Condition="'$(BootstrapBuildToolsDir)' != ''">true</_IsBootstrapping>

<PortableBuild Condition="'$(PortableBuild)' == ''">false</PortableBuild>
<UseSystemLibraries Condition="'$(UseSystemLibraries)' == ''">true</UseSystemLibraries>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to default to true?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured since the biggest users of source-build are Linux distributions and they prefer to use system libraries, the default here should be true. Should I conditionalize things depending on the platform and platform versions?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with keeping this as the default and adjusting later if we find issues.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think defaulting to true is the way to go for the reasons @omajid said. Conditionalizing it isn't needed IMO.

Copy link
Member

@weshaggard weshaggard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change looks reasonable to me. Just the one question of what we think the default should be. I don't personally have a strong opinion on it.

@weshaggard weshaggard merged commit 8d6ecb7 into dotnet:dev/release/2.1 Apr 4, 2018
@omajid
Copy link
Member Author

omajid commented Apr 4, 2018

Thanks for merging this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants