Avoid duplicated dependencies in vs201x toolsets output#106
Open
vadz wants to merge 1 commit into
Open
Conversation
vslavik
approved these changes
Apr 19, 2018
vslavik
left a comment
Owner
There was a problem hiding this comment.
No other comments, I think this is the better fix overall.
| # were given, which means we can't simply iterate over | ||
| # set(prj.dependencies) and need to use this temporary set | ||
| # instead. | ||
| already_seen=set() |
Owner
There was a problem hiding this comment.
My first draft said then it would probably be simpler to instead write
for d in OrderedSet(prj.dependencies):
...But then I grepped the code for such uses and found something better:
from bkl.utils import filter_duplicates
...
for d in filter_duplicates(prj.dependencies):
…do something… Probably doesn't even need the explanatory comments then — it says what it does and it's clear why one might want to eliminate duplicates here...
Collaborator
Author
There was a problem hiding this comment.
Great, thanks for the filter_duplicates() hint!
I'd still keep the comment because it might not be obvious that it's more than just an "optimization".
Although nobody would arguably duplicate the dependencies on purpose, it was easy to do this unintentionally by inheriting a dependency from a base template and also adding it explicitly -- and this, in fact, happened in several places in real projects, resulting in not quite correct solution and project files being generated: such files could still be read by MSVS, but were rewritten by it to prune the duplicate dependencies, resulting in changes compared to the originally generated versions. Avoid this by emitting the dependencies only once in both the solution and the project files: this requires duplicating the duplication pruning logic, but is better than trying to do it at the model level because the dependencies may result from the evaluation of expressions involving the toolset name and other variables, so this approach is much simpler to make work. Also add a unit test verifying that this now behaves as expected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Although nobody would arguably duplicate the dependencies on purpose, it
was easy to do this unintentionally by inheriting a dependency from a
base template and also adding it explicitly -- and this, in fact,
happened in several places in real projects, resulting in not quite
correct solution and project files being generated: such files could
still be read by MSVS, but were rewritten by it to prune the duplicate
dependencies, resulting in changes compared to the originally generated
versions.
Avoid this by emitting the dependencies only once in both the solution
and the project files: this requires duplicating the duplication pruning
logic, but is better than trying to do it at the model level because the
dependencies may result from the evaluation of expressions involving the
toolset name and other variables, so this approach is much simpler to
make work.
Also add a unit test verifying that this now behaves as expected.
This replaces #104.