Use stable outputs in illink targets

[ViktorHofer]

While building locally multiple times, I noticed that the incremental build of the illink-targets are now to aggressive and could cause the targets to either never run or too often. This could be the case when the linker doesn't trim anything and copies the inputs to the outputs directory with preserving the timestamps. In such cases the inputs would always be newer than the outputs and the step would alway run. Also the path that was used to construct the outputs was missing a trailing directory separator. Using a marker file instead to not be dependent on the freshness of the linker output.

[ghost]

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

Issue Details

---

While building locally multiple times, I noticed that the incremental build of the illink-targets are now to aggressive and could cause the targets to either never run or too often. This could be the case when the linker doesn't trim anything and copies the inputs to the outputs directory with preserving the timestamps. In such cases the inputs would always be newer than the outputs and the step would alway run. Also the path that was used to construct the outputs was missing a trailing directory separator. Using a marker file instead to not be dependent on the freshness of the linker output.

Author:	ViktorHofer
Assignees:	ViktorHofer
Labels:	area-Infrastructure-libraries
Milestone:	-

[ViktorHofer]

@safern@ericstj thanks for reviewing the other PRs. Can you please take a look at this one as well?

[ViktorHofer]

I addressed the feedback, please review. Thanks

[ViktorHofer]

@ericstj@safern can you please review and approve?

I also have another few changes waiting for feedback that I would really love to get in:

• Use Reference items instead of P2Ps for inbox libs #64508
• Don't use Targets* helper properties in libs #64500
• Add NetCoreAppCurrent rid agnostic tfm to libs #64518

As soon as those are in, I can finish implementing #64000 and with that probably again spend less time contributing to dotnet/runtime until April ;)