Как бороться с несколькими вложенными корнями рабочей области?

Как вы можете иметь несколько вложенных рабочих областей с помощью Cargo?

У меня есть следующая структура проекта:

myworkspace
├── project_a
│   └── Cargo.toml
├── project_b
│   └── Cargo.toml
│   └── project_b_dependency
|       └── Cargo.toml
└── Cargo.toml

Где project_b_dependency — это большая библиотека, которая представляет собой подмодуль git, который сам по себе имеет рабочее пространство.

Я получаю сообщение об ошибке, когда запускаю cargo build, потому что в рабочей области есть рабочая область.

$ cargo build
error: multiple workspace roots found in the same workspace:
  /myworkspace
  /myworkspace/project_b/project_b_dependency

Есть ли простой обходной путь? Я хочу сохранить project_b_dependency в системе контроля версий как подмодуль.

Это не дубликат рефакторинга структуры рабочей области. приводит к тому, что импорт внешних ящиков не работает, потому что я хочу знать, как я могу работать с вложенными рабочими пространствами.


rust-cargo rust
person Olivier    schedule 16.04.2018    source источник
comment
Возможный дубликат Рефакторинг структуры рабочей области вызывает внешний ящик импорт не работает   -  person AbhiNickz    schedule 16.04.2018
comment
Каким вы хотите видеть поведение? Должен ли cargo build --all помещать все артефакты сборки элементов рабочей области project_b_dependency в целевой каталог myworkspace?   -  person Shepmaster    schedule 16.04.2018
comment
Да, именно такое поведение я и хотел. К счастью, все смогли ответить на мой вопрос.   -  person Olivier    schedule 17.04.2018

Ответы (3)


arrow_upward
3
arrow_downward

Кажется, что вложенными рабочими пространствами довольно сложно управлять, поэтому одна из возможностей — изменить макет вашего проекта:

.
├── myworkspace
│   ├── Cargo.lock
│   ├── Cargo.toml
│   ├── project_a
│   │   ├── Cargo.toml
│   │   └── src
│   │       └── lib.rs
│   ├── project_b
│   │   ├── Cargo.toml
│   │   └── src
│   │       └── lib.rs
│   └── src
│       └── main.rs
└── project_b_dependency
    ├── Cargo.toml
    └── src
        └── lib.rs

in myworkspace/Cargo.toml:

[workspace]
members= ["project_a", "project_b"]

In myworkspace/project_b/Cargo.toml

[dependencies]
project_b_dependency = {path = "../../project_b_dependency"}

Я пытался использовать свойство workspace.exclude с вашим макетом, но безуспешно.

person attdona    schedule 16.04.2018
comment
Означает ли это, что рабочее пространство project_b_dependency можно импортировать только все сразу? Или я могу импортировать только один из его ящиков? - person Boiethios; 03.03.2021

arrow_upward
5
arrow_downward

Рабочие области не могут быть вложенными; как указано в в документах:

Крейт может указывать либо package.workspace, либо указывать [workspace]. То есть ящик не может одновременно быть корневым ящиком в рабочей области (содержать [workspace]) и одновременно быть элементом другого рабочего пространства (содержать package.workspace).

Рабочая область Cargo RFC также указал это:

Рабочая область действительна, если выполняются эти два свойства:

  • Рабочее пространство имеет только один корневой ящик (с [workspace] в Cargo.toml).
  • Все ящики рабочей области, определенные в workspace.members, указывают на корень рабочей области с помощью package.workspace.
person ljedrz    schedule 16.04.2018
comment
После этого сообщения в настоящее время это возможно как документы теперь состояние. Также: An empty [workspace] table can be used with a [package] to conveniently create a workspace with the package and all of its path dependencies. - person Raphaël Duchaîne; 29.10.2020

arrow_upward
0
arrow_downward

Я нахожу способ сохранить подмодуль git.

  1. Добавьте членов рабочей области проекта подмодуля в родительский Cargo.toml
  2. Удалить Cargo.toml проекта подмодуля
  3. Используйте submodule_name/crate path для определения зависимости.
person jolestar    schedule 11.09.2019