Skip to content

Bugfix/cmdline deptypes#2307

Merged
tgamblin merged 1 commit intospack:developfrom
scheibelp:bugfix/cmdline-deptypes
Dec 8, 2016
Merged

Bugfix/cmdline deptypes#2307
tgamblin merged 1 commit intospack:developfrom
scheibelp:bugfix/cmdline-deptypes

Conversation

@scheibelp
Copy link
Copy Markdown
Member

Fixes #2306

Any dependency specified on the command line ended up with the build
and link deptypes unconditionally. This makes it so for example if
cmake is mentioned as a dependency it gets the build deptype only.

I need to make sure this handles keeping dependents and dependencies in sync. Otherwise I think it is close

@scheibelp
Copy link
Copy Markdown
Member Author

This is ready to merge. It will have some trivial conflicts with #2292

Fixes spack#2306

Any dependency explicitly mentioned in a spec string ended up with the
build and link deptypes unconditionally. This fixes dependency
resolution to ensure that packages which are mentioned in the spec
string have their deptypes determined by the dependency information
in the package.py files. For example if a package has cmake as a build
dependency, and cmake is mentioned as a dependency in the spec string
for the package, then it ends up with just the build deptype.
@scheibelp scheibelp force-pushed the bugfix/cmdline-deptypes branch from 4214a89 to d9970b3 Compare December 8, 2016 02:19
@tgamblin tgamblin merged commit 83c9f7a into spack:develop Dec 8, 2016
kserradell pushed a commit to kserradell/spack that referenced this pull request Dec 9, 2016
Fixes spack#2306

Any dependency explicitly mentioned in a spec string ended up with the
build and link deptypes unconditionally. This fixes dependency
resolution to ensure that packages which are mentioned in the spec
string have their deptypes determined by the dependency information
in the package.py files. For example if a package has cmake as a build
dependency, and cmake is mentioned as a dependency in the spec string
for the package, then it ends up with just the build deptype.
tgamblin added a commit that referenced this pull request Dec 25, 2016
- Fixes issues with hashing where deptypes from one dependency would be
  overwritten by those of another dependency on the same package.

- Copying specs (`Spec.copy()`, `Spec._dup()`) did not handle deptypes
  correctly:

  - Copying "flattened" dependencies, but in doing so it collapsed
    multiple dependency relationships into one, losing some edge
    information in the DAG.

  - This gets rid of the `flat_dependencies_with_deptypes()` method,
    which doesn't really make sense, as it collapses edges. It's now
    reverted the original `flat_dependnecies()`.

  - `traverse_with_deptypes()` is now called `traverse_edges()`, which is
    when edge information must be preserved.

- This gets rid of the notion of "default deptypes" introduced in #2307.

  - Initially created Specs now have empty deptypes instead of "defaults".

  - Proper deptypes are added during normalization/concretization like
    everything else in the Spec class.  Empty deptypes mean deptypes are
    not yet specified, and the spec is abstract.

- Updated tests.
@tgamblin tgamblin mentioned this pull request Dec 25, 2016
5 tasks
tgamblin added a commit that referenced this pull request Dec 25, 2016
- Fixes issues with hashing where deptypes from one dependency would be
  overwritten by those of another dependency on the same package.

- Copying specs (`Spec.copy()`, `Spec._dup()`) did not handle deptypes
  correctly:

  - Copying "flattened" dependencies, but in doing so it collapsed
    multiple dependency relationships into one, losing some edge
    information in the DAG.

  - This gets rid of the `flat_dependencies_with_deptypes()` method,
    which doesn't really make sense, as it collapses edges. It's now
    reverted the original `flat_dependnecies()`.

  - `traverse_with_deptypes()` is now called `traverse_edges()`, which is
    when edge information must be preserved.

- This gets rid of the notion of "default deptypes" introduced in #2307.

  - Initially created Specs now have empty deptypes instead of "defaults".

  - Proper deptypes are added during normalization/concretization like
    everything else in the Spec class.  Empty deptypes mean deptypes are
    not yet specified, and the spec is abstract.

- Updated tests.
tgamblin added a commit that referenced this pull request Dec 29, 2016
- Fixes issues with hashing where deptypes from one dependency would be
  overwritten by those of another dependency on the same package.

- Copying specs (`Spec.copy()`, `Spec._dup()`) did not handle deptypes
  correctly:

  - Copying "flattened" dependencies, but in doing so it collapsed
    multiple dependency relationships into one, losing some edge
    information in the DAG.

  - This gets rid of the `flat_dependencies_with_deptypes()` method,
    which doesn't really make sense, as it collapses edges. It's now
    reverted the original `flat_dependnecies()`.

  - `traverse_with_deptypes()` is now called `traverse_edges()`, which is
    when edge information must be preserved.

- This gets rid of the notion of "default deptypes" introduced in #2307.

  - Initially created Specs now have empty deptypes instead of "defaults".

  - Proper deptypes are added during normalization/concretization like
    everything else in the Spec class.  Empty deptypes mean deptypes are
    not yet specified, and the spec is abstract.

- Updated tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Deptypes Incorrect for dependencies specified on command line

3 participants