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

Use .Net Core MSBuild for OS X and Linux Builds #5711

Merged
merged 1 commit into from Jan 28, 2016

Conversation

Projects
None yet
7 participants
@joperezr
Member

joperezr commented Jan 26, 2016

Use .Net Core MSBuild for OS X and Linux Builds

Show outdated Hide outdated dir.props Outdated
Show outdated Hide outdated dir.props Outdated
@mellinoe

This comment has been minimized.

Show comment
Hide comment
@mellinoe

mellinoe Jan 26, 2016

Contributor

I can test this on my machine when the packages have been uploaded to buildtools and the temporary sources are removed, since the CI won't be building any of this.

I'm happy to see this is finally going in, it should hopefully get us much closer to a unified build process for x-plat builds.

Contributor

mellinoe commented Jan 26, 2016

I can test this on my machine when the packages have been uploaded to buildtools and the temporary sources are removed, since the CI won't be building any of this.

I'm happy to see this is finally going in, it should hopefully get us much closer to a unified build process for x-plat builds.

@joperezr

This comment has been minimized.

Show comment
Hide comment
@joperezr

joperezr Jan 27, 2016

Member

@mellinoe I just pushed a change to my buildtools PR dotnet/buildtools#396 that removes the temporary sources given that I'm done pushing the packages into the buildtools feed now. That means that you should be able to sync to my branch in buildtools and build to produce a buildtools package, and use that to build xplat using the code in this PR.

Member

joperezr commented Jan 27, 2016

@mellinoe I just pushed a change to my buildtools PR dotnet/buildtools#396 that removes the temporary sources given that I'm done pushing the packages into the buildtools feed now. That means that you should be able to sync to my branch in buildtools and build to produce a buildtools package, and use that to build xplat using the code in this PR.

@joperezr

This comment has been minimized.

Show comment
Hide comment
@joperezr
Member

joperezr commented Jan 27, 2016

Show outdated Hide outdated dir.props Outdated
Show outdated Hide outdated dir.props Outdated
@mellinoe

This comment has been minimized.

Show comment
Hide comment
@mellinoe

mellinoe Jan 27, 2016

Contributor

@joperezr I think there may be an issue with the Open signing key. So far most of the projects have built fine, but I'm getting this error from the projects that do use the new key:

CSC : error CS7027: Error signing output with public key from file '/home/eric/projects/corefx/Tools/Open.snk' -- Cannot marshal 'return value': Invalid managed [/home/eric/projects/corefx/src/System.Diagnostics.DiagnosticSource/src/System.Diagnostics.DiagnosticSource.csproj]

Still running the build (haven't gotten to to tests or packaging yet), but everything seems to be running smoothly other than the above.

Contributor

mellinoe commented Jan 27, 2016

@joperezr I think there may be an issue with the Open signing key. So far most of the projects have built fine, but I'm getting this error from the projects that do use the new key:

CSC : error CS7027: Error signing output with public key from file '/home/eric/projects/corefx/Tools/Open.snk' -- Cannot marshal 'return value': Invalid managed [/home/eric/projects/corefx/src/System.Diagnostics.DiagnosticSource/src/System.Diagnostics.DiagnosticSource.csproj]

Still running the build (haven't gotten to to tests or packaging yet), but everything seems to be running smoothly other than the above.

@joperezr

This comment has been minimized.

Show comment
Hide comment
@joperezr

joperezr Jan 27, 2016

Member

@mellinoe yeah I saw that as well, that started happening this morning when I rebased. It seems to be a compiler bug, I'll log the issue and push the workaround

Member

joperezr commented Jan 27, 2016

@mellinoe yeah I saw that as well, that started happening this morning when I rebased. It seems to be a compiler bug, I'll log the issue and push the workaround

@mellinoe

This comment has been minimized.

Show comment
Hide comment
@mellinoe

mellinoe Jan 27, 2016

Contributor

Workaround looks fine to me. Like I mentioned, we are doing the same thing with the ECMA key right now.

EDIT: Actually, maybe we should make the workaround the same as the ECMA Key one:

https://github.com/dotnet/corefx/blob/0dd1ab7223dea82f236ec81d42f4ae0227176bf4/dir.props

<!--
      Delay signing with the ECMA key currently doesn't work.
      https://github.com/dotnet/roslyn/issues/2444
    -->
    <UseECMAKey>false</UseECMAKey>

In the project files we just do:

<UseECMAKey Condition="'$(UseECMAKey)' == ''">true</UseECMAKey>

I'm fine either way, but it might be nice to have both of these properties in one place so we can remember to address them both (I'm assuming they're related)

Contributor

mellinoe commented Jan 27, 2016

Workaround looks fine to me. Like I mentioned, we are doing the same thing with the ECMA key right now.

EDIT: Actually, maybe we should make the workaround the same as the ECMA Key one:

https://github.com/dotnet/corefx/blob/0dd1ab7223dea82f236ec81d42f4ae0227176bf4/dir.props

<!--
      Delay signing with the ECMA key currently doesn't work.
      https://github.com/dotnet/roslyn/issues/2444
    -->
    <UseECMAKey>false</UseECMAKey>

In the project files we just do:

<UseECMAKey Condition="'$(UseECMAKey)' == ''">true</UseECMAKey>

I'm fine either way, but it might be nice to have both of these properties in one place so we can remember to address them both (I'm assuming they're related)

@weshaggard

This comment has been minimized.

Show comment
Hide comment
@weshaggard

weshaggard Jan 27, 2016

Member

I kind of agree with @mellinoe that we should probably just add the explicit set to false in the same place and in the individual projects only set it to true if the property is empty.

Member

weshaggard commented Jan 27, 2016

I kind of agree with @mellinoe that we should probably just add the explicit set to false in the same place and in the individual projects only set it to true if the property is empty.

@joperezr

This comment has been minimized.

Show comment
Hide comment
@joperezr

joperezr Jan 28, 2016

Member

@weshaggard @mellinoe Sounds good, I'll do that.

Member

joperezr commented Jan 28, 2016

@weshaggard @mellinoe Sounds good, I'll do that.

@weshaggard

This comment has been minimized.

Show comment
Hide comment
@weshaggard

weshaggard Jan 28, 2016

Member

LGTM please make sure to file the various tracking bugs for the comments.

Member

weshaggard commented Jan 28, 2016

LGTM please make sure to file the various tracking bugs for the comments.

@weshaggard

This comment has been minimized.

Show comment
Hide comment
@weshaggard

weshaggard Jan 28, 2016

Member

@dotnet-bot test Innerloop OSX Release Build and Test

Member

weshaggard commented Jan 28, 2016

@dotnet-bot test Innerloop OSX Release Build and Test

@mellinoe

This comment has been minimized.

Show comment
Hide comment
@mellinoe

mellinoe Jan 28, 2016

Contributor

LGTM

Contributor

mellinoe commented Jan 28, 2016

LGTM

joperezr added a commit that referenced this pull request Jan 28, 2016

Merge pull request #5711 from joperezr/RestoreMSBuild
Use .Net Core MSBuild for OS X and Linux Builds

@joperezr joperezr merged commit ab6ec2f into dotnet:master Jan 28, 2016

10 checks passed

Innerloop CentOS7.1 Debug Build and Test Build finished. No test results found.
Details
Innerloop CentOS7.1 Release Build and Test Build finished. No test results found.
Details
Innerloop OSX Debug Build and Test Build finished. No test results found.
Details
Innerloop OSX Release Build and Test Build finished. No test results found.
Details
Innerloop OpenSUSE13.2 Debug Build and Test Build finished. No test results found.
Details
Innerloop OpenSUSE13.2 Release Build and Test Build finished. No test results found.
Details
Innerloop Ubuntu Debug Build and Test Build finished. No test results found.
Details
Innerloop Ubuntu Release Build and Test Build finished. No test results found.
Details
Innerloop Windows_NT Debug Build and Test Build finished. 111196 tests run, 32 skipped, 0 failed.
Details
Innerloop Windows_NT Release Build and Test Build finished. 111193 tests run, 32 skipped, 0 failed.
Details

@joperezr joperezr deleted the joperezr:RestoreMSBuild branch Jan 28, 2016

@ghost ghost referenced this pull request Jan 30, 2016

Closed

Clean up build.sh and mono.targets #5743

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 18, 2016

@ellismg, can we have a similar upgrade in CoreCLR? Currently building CoreCLR on NetBSD is requiring Mono; which unlike FreeBSD is bit more inconvenient -- although we have installed full mono packs on our systems, but this is something we would greatly appreciate and even willing to pull off ourselves (by taking inspirations from @joperezr's work in this PR), if we get a 'go ahead'. =)

ghost commented Feb 18, 2016

@ellismg, can we have a similar upgrade in CoreCLR? Currently building CoreCLR on NetBSD is requiring Mono; which unlike FreeBSD is bit more inconvenient -- although we have installed full mono packs on our systems, but this is something we would greatly appreciate and even willing to pull off ourselves (by taking inspirations from @joperezr's work in this PR), if we get a 'go ahead'. =)

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Feb 18, 2016

Contributor

@jasonwilliams200OK We are 99.99% of the way there, and dotnet/coreclr#3214 will remove the last mono dependency.

Contributor

ellismg commented Feb 18, 2016

@jasonwilliams200OK We are 99.99% of the way there, and dotnet/coreclr#3214 will remove the last mono dependency.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 18, 2016

Thanks @ellismg! Perfect timings I'd say.. 🎯

ghost commented Feb 18, 2016

Thanks @ellismg! Perfect timings I'd say.. 🎯

@karelz karelz added this to the 1.0.0-rtm milestone Dec 3, 2016

@karelz karelz added this to the 1.0.0-rtm milestone Dec 3, 2016

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