-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
-getTargetResult
+ -target
behavior is unexpected
#9225
Comments
I think we should disallow |
Myself I think that limiting results reporting to just the entry point targets is too limiting. |
This may have been a part of a design discussion that wasn't fully fleshed out, but having -getTargetResult add the targets it wants to execute to the list of targets that need to be executed was how I'd intended for it to work. We can't return results from targets that don't execute, so we clearly have to include targets listed in -getTargetResult. If you request more targets via -target, I think that should be permitted because otherwise, you wouldn't be able to ask for the result of Two in the context of One having been executed. (Like imagine if One doesn't have any connection to Two as far as MSBuild is concerned but does change some files on disk...well, then it may indirectly affect Two, and we'd need a way to say "I want One and Two to execute, but I only care about the result from Two.") So my personal take is that this is exactly the desired behavior, but I'll @baronfel for a more official opinion. |
Isn't that |
That's something you can do, and in your example, it would be pretty reasonable. One could potentially have an enormous list of results, though, and many users are very concerned with not having excess information thrown around. If they want everything, they can just look at a binlog. Having the two flags separate permits more precision on the part of the user. |
I'm in favor of not coupling the "entry point" targets and the "result" targets. I'm not in favor of having two switches define the "entry point" targets. It does appear that the targets in
I'm not on board with the assumption that every target in {
"TargetResults": {
}
} This could be a quick troubleshooting technique without checking logs or adding I think it is reasonable and a better separation of responsibilities, that |
@baronfel, I think this fell through the cracks at some point. I still think the current design is the best option available, but since there's some disagreement on that point, it'd be good to get some resolution. My reasons:
This is sorta true but more incidentally than intentionally. That's often the result of specifying that a particular target should build: it builds all the things it depends on before it itself builds. If you have AfterTargets="Foo", though, that target will build after any targets you specify. They just shouldn't affect the results.
I think this is a very good point. It raises the question as to whether people are more likely to be surprised by an empty target result (and probably think the feature isn't working as a result) or unhappy because there's no easy way to check whether a target should run. I don't know the answer to that. My personal take is that the former is more important because if I want to know whether a target ran or not, once I have the answer, my next question is 'why', and you wouldn't get that out of this; you'd have to look at logs. But that's just how I would go about it, so I'm curious to hear what @baronfel thinks. |
-getTargetResult
will run a target that otherwise would not run.E.g. Given a project with targets
one
andtwo
and the targets have no dependency between them:and given a command line with
-target:one -getTargetResult:two
, both targets will be executed.The current behavior executes the targets provided to
-getTargetResult
that didn't already execute, after the 'standard' target build order. Essentially there is a secondary chain of targets.It seems from the discussion that this is not the intended behavior.
My own quick take is that
-getTargetResult
should not itself cause a target to be executed and if a target provided to-getTargetResult
didn't execute then there is no result to report.Originally posted by @jrdodds in #3911 (comment)
The text was updated successfully, but these errors were encountered: