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

Package Native AOT C++ sources for separate compilation on customer machines #102586

Closed
agocke opened this issue May 22, 2024 · 4 comments
Closed

Comments

@agocke
Copy link
Member

agocke commented May 22, 2024

In some cases, users might want to compile for platforms that .NET doesn't support. Providing the sources (and CMake build files) for external compilation would allow for broader platform builds without increased cost on the runtime side.

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label May 22, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label May 22, 2024
@agocke agocke added area-NativeAOT-coreclr and removed untriaged New issue has not been triaged by the area owner needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels May 22, 2024
@agocke agocke added this to the Future milestone May 22, 2024
Copy link
Contributor

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

@jkoritzinsky
Copy link
Member

For this scenario, we should produce simple and straightforward CMake files that have the minimal information required to define the CMake targets necessary to build the libraries. Right now we have a decent amount of logic that's shared with the rest of the runtime repo (functions, shared definitions), and I don't think we want to ship our eng/native directory.

@MichalStrehovsky
Copy link
Member

Is this a duplicate of #83611?

I've looked at this in the past, and yeah, the shared CMake files don't make it easy to disconnect from our engineering system. But if we don't use the same files that we use to build the product, it's super easy to forget switches/ifdefs and end up with a different runtime, that could be different in very subtle ways. It also doesn't help that CoreLib relies on files we generate as part of native build and who knows if they could be different.

@jkotas
Copy link
Member

jkotas commented May 23, 2024

Yes, this is duplicate of #83611

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

No branches or pull requests

4 participants