Skip to content

Avoid duplicated dependencies in vs201x toolsets output#106

Open
vadz wants to merge 1 commit into
masterfrom
unique-deps-vs
Open

Avoid duplicated dependencies in vs201x toolsets output#106
vadz wants to merge 1 commit into
masterfrom
unique-deps-vs

Conversation

@vadz

@vadz vadz commented Apr 19, 2018

Copy link
Copy Markdown
Collaborator

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.

@vslavik vslavik left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No other comments, I think this is the better fix overall.

Comment thread src/bkl/plugins/vsbase.py Outdated
# were given, which means we can't simply iterate over
# set(prj.dependencies) and need to use this temporary set
# instead.
already_seen=set()

@vslavik vslavik Apr 19, 2018

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants