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

Consider making _GetProjectReferenceTargetFrameworkProperties target incremental #2309

Closed
KirillOsenkov opened this issue Jul 16, 2017 · 5 comments
Labels
Area: Common Targets Area: Debuggability Issues impacting the diagnosability of builds, including logging and clearer error messages. triaged

Comments

@KirillOsenkov
Copy link
Member

Currently when building a codebase the second time the only target we see built from scratch is:
Building target "_GetProjectReferenceTargetFrameworkProperties" completely.

I realize that it's possibly by design but it would be really convenient if that target somehow specified inputs and outputs if at all possible. This way we can simply search the build log for "Building target completely" and if we didn't find it, it means the build was fully incremental with no unnecessary rebuilding.

This is the only target that I see currently always "rebuilding", even though it may be by design.

This is a nice to have.

@KirillOsenkov
Copy link
Member Author

/cc @nguerrera

@KirillOsenkov
Copy link
Member Author

image

@rainersigwald rainersigwald added the Area: Debuggability Issues impacting the diagnosability of builds, including logging and clearer error messages. label Jul 17, 2017
@rainersigwald
Copy link
Member

This will be fixed with basically any fix of the double-evaluation problem. The reason there's an Output specified for that target is just to batch over multiple references, which should be fixed to do them all in parallel (and my proposed improvements do just that).

Because of that I'm going to claim this is a duplicate of #1276 even though it could be fixed independently (by switching the batching to be based on an always-true condition).

@KirillOsenkov
Copy link
Member Author

Perfect, that works for me!

@rainersigwald
Copy link
Member

And this is actually fully a duplicate of #1785, so I'm going to close it.

@rainersigwald rainersigwald marked this as a duplicate of #1785 Jul 19, 2017
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Common Targets Area: Debuggability Issues impacting the diagnosability of builds, including logging and clearer error messages. triaged
Projects
None yet
Development

No branches or pull requests

3 participants