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

Move src/native libraries that are shared between runtime builds to be targets-driven #103184

Merged
merged 31 commits into from
Jun 24, 2024

Conversation

jkoritzinsky
Copy link
Member

Today, the src/native/containers and src/native/eventpipe libraries are defined in terms of source and header file lists.

This provides flexibility into how they're defined in CMake, but it makes it difficult to flow include directories or dependencies. It also makes it difficult to encapsulate logic, as these lists are defined in .cmake files that are included into a CMakeLists.txt file.

This PR converts these libraries to be defined in terms of CMake targets.

src/native/containers is transformed into an object library, so we can build it once and then link it into static libs, shared libs, or executables. An extern "C" block was added around all declarations that are currently used in eventpipe/diagnosticserver (so not dn-simdhash) to enable the build to build the containers library as a C library. Also, a default implementation of the dn_simdhash_assert_fail method was added to enable the containers lib to link into runtimes that don't currently provide an implementation.

src/native/eventpipe is transformed into interface libraries. Due to how eventpipe and diagnosticserver both require runtime-specific headers and need to be built with different flags for each target, defining them as interface libraries is the cleanest manner to handle this scenario (until we can refactor the ep-rt-*.h and ds-rt-*.h headers into a cleaner design).

This PR also updates the eventpipe and diagnosticserver codebases to use CMake's UNITY_BUILD support in each runtime's implementation instead of manually implementing a unity build.

Copy link
Contributor

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

@lambdageek
Copy link
Member

lambdageek commented Jun 10, 2024

FYI there's some eventpipe and containers unit tests in https://github.com/dotnet/runtime/tree/main/src/mono/mono/eventpipe/test that (AFAIK) don't run on any pipeline, but that is used for local validation of EP or container changes

…raries, and update CoreCLR to use the new model.
… there's very few reasons to use it in this way, but this is one of the scenarios for it).
#include <stdio.h>
#include <stdlib.h>

// Define a default implementation of the assert failure function.
Copy link
Member

Choose a reason for hiding this comment

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

Should we put something like this in minipal? it seems generally useful

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 think I'd like to see more places where we'd use it before I move it to minipal. We can extract it the next time we'd have a use for it.

@jkoritzinsky
Copy link
Member Author

/ba-g Wasm firefox timeout seems unrelated.

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

Successfully merging this pull request may close these issues.

2 participants