Build the cdac as part of clr.tools instead of as a prereq to the runtime native build #109598
Conversation
…time native build Fixes dotnet#104158 This will also allow us to take a dependency on native components from the cdacreader project when necessary without too much difficulty (ie. native unwinder)
AaronRobinsonMSFT
left a comment
There was a problem hiding this comment.
I like the idea. I defer to @elinor-fung for confirmation this is the right place.
|
Did you consider making it it's own subset or folding into a new unified subset with existing linuxdac subset? Adding new ILC-compiled things noticeably slows down the build. (I already have cdac commented out locally to speed up my builds and wanted to do some PR about it at some point; this PR looks like a good general direction.) |
|
We should be able to further simplify the duplicate props am11@7bba405. |
I considered putting it into its own subset (as tools.cdacreader or something like that), but I didn't want to break the dev workflow of the people who work on it regularly. I don't like putting it into If the people who work on cDAC regularly (all tagged for reviewing this PR) are okay with it being in a |
|
I'm fine with a separate subset that stays part of PR/CI builds but not part of clr.runtime/tools (agreed that I wouldn't want it with the cross-OS DACs). I think it is a reasonable logical split and a trivial change to the cDAC development workflow for significant benefit to other workflows. |
…s part of the tools subset)
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
|
@elinor-fung can you take another look at this PR when you have a chance? |
|
/ba-g unrelated timeout |
…time native build (dotnet#109598)
Fixes #104158
This will also allow us to take a dependency on native components from the cdacreader project when necessary without too much difficulty (ie. native unwinder)