Add components to the coreclr native build

[jashook]

Currently it is possible on windows to build components of the build by rebuilding a specific vcxproj and this hack is the only way to build a subtree. This does not translate well to other platforms, or other generators like ninja.

Doing this work will allow building portions of the runtime. One could imagine for example build.sh -s clr.jit or build.sh -s clr.gc.

[jashook]

/cc @jkoritzinsky

[janvorli]

What would be the benefit of this? If you build the coreclr once, then making changes in say jit or gc rebuilds just that component and on Unix, the build skims over the up-to date components very quickly (in a matter of few seconds).

[MichalStrehovsky]

the build skims over the up-to date components very quickly (in a matter of few seconds).

A few seconds for a no-op is still pretty annoying to wait for. When I'm doing crossgen2 work, I often only care about RyuJIT. Skipping the rest of the native build would save me minutes.

[janvorli]

I meant that it skims over all the up to date components in a matter of seconds. So it is not clear to me how it would save minutes. Native part of build-runtime.sh when all components are up to date takes 7 seconds on my 8+ years old devbox.

[jashook]

Right the other bit is that this is the case on unix; however, unless you are familiar enough with the build system to open a specific vcxproj and rebuild that on windows. The rebuild cycle is less efficient.

[MichalStrehovsky]

So it is not clear to me how it would save minutes.

Sorry, I should have split that into two paragraphs.

The second paragraph would start with the "When I'm doing crossgen2 work, I often only care about RyuJIT.". Being able to build just RyuJIT after a git pull would save me minutes - I rarely care about rebuilding DAC, VM and the other stuff. JIT has a well defined interface with the runtime so often rebuilding just that after a git pull produces a working product (and it's easy to detect when it doesn't because the JitInterface GUID changed). I have very little patience when it comes to CoreCLR build because I'm used to build times of managed code.

[janvorli]

Ah, ok, makes sense then.

[AntonLapounov]

I think this has been implemented by #49906. Should we close this?

[jkoritzinsky]

Yes, this has been implemented.