LINUX.ORG.RU

Cargo, несколько таргетов

 


0

3

В прошлый раз на мои вопросы по расту успешно ответили, так что попробую ещё раз.

Хочу сделать следующее: два таргета использующих один модуль. Проще, наверное, будет кодом показать.

Структура проекта:

project
├── shared
│   └── mod.rs
├── target_1
│   └── main.rs
├── target_2
│   └── main.rs
Да, я в курсе, что рекомендуется иметь «src» директорию. Но честно говоря, не понимаю как она тут поможет. Да и не хочется идти по такому пути.

Cargo.toml

[[bin]]
name = "target_1"
path = "target_1/main.rs"

[[bin]]
name = "target_2"
path = "target_2/main.rs"

target_1/main.rs

#![feature(globs)]

mod shared;
use shared::*;

Получаю ошибку:

error: file not found for module `shared`

help: name the file either shared.rs or shared/mod.rs inside the directory target_1

Есть ли способ указать директорию «project» как корень для поиска модулей?

ozkriff tailgunner

★★★★★

Есть ли способ указать директорию «project» как корень для поиска модулей?

Способа нет.

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

DarkEld3r ★★★★★
() автор топика

Такое чувство что rust погубит такой вот кривой инструментарий. Ну и ещё отсутствие нормальных исключений.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Такое чувство что rust погубит такой вот кривой инструментарий.

Ну конкретно этот момент скорее странный. Я так и не понял почему нет способа сделать нормально. Хотя обходится оно весьма легко и «лишние зависимости» не такая и проблема - всё равно они не линкуются, если не использовать.

Меня больше напрягает их «принципиальность» (или скорее упёртость). Тут и всякие умолчания в организации проектов - хорошо хоть, с горем пополам, настраиваются, но хаскелевский кабал и то оказался удобнее в этом плане. И «встроенный» контроль за именованием (вместо отдельной тулзы с настраиваемыми правилами). Ну и исключения сюда же - в обсуждениях даже говорилось, что сделать их не проблема, но «не хотим».

Это кажется странным ещё и потому что так сложнее мигрировать на раст. То есть людям помимо изучения языка ещё и ломать привычки приходится.

DarkEld3r ★★★★★
() автор топика
Ответ на: комментарий от numas13

Можно указать путь к модулю.

Не знал, спасибо. Тем не менее, вариант с перемещением модуля в зависимости проекта кажется более прямым - не очень нравится идея хардкодить пути, пусть и относительные.

DarkEld3r ★★★★★
() автор топика
Ответ на: комментарий от DarkEld3r

Тем не менее, вариант с перемещением модуля в зависимости проекта кажется более прямым - не очень нравится идея хардкодить пути, пусть и относительные.

На самом деле это очень мощный механизм. К примеру.

#[cfg(unix)
#[path="unix/mod.rs"]
mod os;

#[cfg(windows)
#[path="windows/mod.rs"]
mod os;

Но если он тебе не подходит, можно выделить модуль в отдельный rlib.

# project/shared/Cargo.toml
[lib]
name = "shared"
path = "lib.rs"

# project/Cargo.toml
[dependencies.shared]
path = "shared"
# project/target_1/main.rs
extern crate shared;
numas13
()
Ответ на: комментарий от numas13

На самом деле это очень мощный механизм. К примеру.

Не спорю. И приведённый пример хорош, но если говорить о моём случае, то видеть в проекте пути типа "../../../shared/mod.rs" не особо нравится. Хотя ещё подумаю, может мнение изменю. Из плюсов вижу то, что нет необходимости писать отдельный Cargo.toml для либы.

Но если он тебе не подходит, можно выделить модуль в отдельный rlib.

Да, так и сделал. Смущает, что зависимости одни на проект и я никак не могу отразить тот факт, что отдельные «таргеты» используют не все зависимости.

DarkEld3r ★★★★★
() автор топика
Ответ на: комментарий от numas13

На самом деле это очень мощный механизм. К примеру.
Но если он тебе не подходит, можно выделить модуль в отдельный rlib.

А на твой взгляд, что лучше: использовать зависимости или «пути»?

Ещё вижу следующий плюс у зависимостей - они будут собираться один раз, если же использовать путь к модулю, то он будет обрабатываться несколько раз. Так?

DarkEld3r ★★★★★
() автор топика
Ответ на: комментарий от DarkEld3r

А на твой взгляд, что лучше: использовать зависимости или «пути»?

Если нет межмодульных зависимостей от target_{1,2}, я бы использовал модуль shared как отдельную библиотеку.

Ещё вижу следующий плюс у зависимостей - они будут собираться один раз, если же использовать путь к модулю, то он будет обрабатываться несколько раз. Так?

Да.

numas13
()
Ответ на: комментарий от numas13

Если нет межмодульных зависимостей от target_{1,2}, я бы использовал модуль shared как отдельную библиотеку.

Ясно, спасибо.

DarkEld3r ★★★★★
() автор топика
Ответ на: комментарий от DarkEld3r

Меня больше напрягает их «принципиальность» (или скорее упёртость).

Всё правильно делают.

Тут и всякие умолчания в организации проектов

Унификация.

И «встроенный» контроль за именованием

Круче только в Go пошли.

Ну и исключения сюда же

При существующей системе типов в них нет смысла.

mix_mix ★★★★★
()
Ответ на: комментарий от mix_mix

Всё правильно делают.

Нет.

Унификация.

Большинство языков без этого отлично живут. Да и для нового языка, которым может (и должен) привлечь аудиторию других - это скорее минус.

Круче только в Go пошли.

И что?

При существующей системе типов в них нет смысла.

Да ладно?

DarkEld3r ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.