ошибка отсутствия ящика, даже если она присутствует в файле Cargo.toml

#rust #gtk #rust-cargo #meson-build #gtk-rs

Вопрос:

У меня есть базовый проект gtk-rs, в котором я использую meson. Я включил ящик gtk4 в файл Cargo.toml. Когда я запускаю с грузом, он компилируется, но выдает ошибку «ошибка сегментации» (я искал и до сих пор не знаю, что это такое). Однако, когда я запускаю meson, он вообще отказывается строиться.

 builddir/
 main.p/
 build.ninja
src/
 main.rs
target/
 ...
Cargo.toml
Cargo.lock
meson.build
 

Груз.томл

 [package]
name = "my-gtk-app"
version = "0.1.0"
edition = "2018"
[dependencies]
gtk = { version = "0.2", package = "gtk4" }
 

мезон.сборка

 project(
  'my-gtk-app',
  'rust',
  version : '0.1',
)
cargo_sources = files(
  'Cargo.toml',
  'Cargo.lock',
)
gtk = dependency('gtk4', version: '>= 4.0.0')
executable('main', 'src/main.rs', dependencies : gtk)
 

main.rs

 use gtk::prelude::*;
use gtk::{Application, ApplicationWindow};

fn main() {
    let app = Application::builder()
        .application_id("org.example.HelloWorld")
        .build();

    app.connect_activate(|app| {
        // We create the main window.
        let window = ApplicationWindow::builder()
            .application(app)
            .default_width(320)
            .default_height(200)
            .title("Hello, World!")
            .build();

        // Show the window.
        window.show();
    });

    app.run();
}
 

Когда я запускаю программу с помощью cargo run , я получаю

 Finished dev [unoptimized   debuginfo] target(s) in 0.45s
Running `target/debug/my-gtk-app`
1] 73039 segmentation fault  cargo run
 

Однако, когда я бегаю с с meson compile -C builddir , я получаю

 ninja: Entering directory `builddir'
[1/1] Compiling Rust source ../src/main.rs
FAILED: main 
rustc -C linker=cc --color=always --crate-type bin --crate-name main -g --emit dep-info=main.d --emit link -o main -L/usr/local/Cellar/gtk4/4.4.0/lib -L/usr/local/Cellar/pango/1.48.10/lib -L/usr/local/Cellar/harfbuzz/3.0.0/lib -L/usr/local/Cellar/gdk-pixbuf/2.42.6/lib -L/usr/local/Cellar/cairo/1.16.0_5/lib -L/usr/local/Cellar/graphene/1.10.6/lib -L/usr/local/Cellar/glib/2.70.0_1/lib -L/usr/local/opt/gettext/lib -l dylib=gtk-4 -l dylib=pangocairo-1.0 -l dylib=pango-1.0 -l dylib=harfbuzz -l dylib=gdk_pixbuf-2.0 -l dylib=cairo-gobject -l dylib=cairo -l dylib=graphene-1.0 -l dylib=gio-2.0 -l dylib=gobject-2.0 -l dylib=glib-2.0 -l dylib=intl ../src/main.rs
error[E0433]: failed to resolve: maybe a missing crate `gtk`?
 --> ../src/main.rs:1:5
  |
1 | use gtk::prelude::*;
  |     ^^^ maybe a missing crate `gtk`?

error[E0432]: unresolved import `gtk`
 --> ../src/main.rs:2:5
  |
2 | use gtk::{Application, ApplicationWindow};
  |     ^^^ maybe a missing crate `gtk`?

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0432, E0433.
For more information about an error, try `rustc --explain E0432`.
ninja: build stopped: subcommand failed.
 

Я на macOS, если это поможет.

Комментарии:

1. Похоже meson , что это вызов rustc (не cargo ) и игнорирование вашей Cargo.toml (или, по крайней мере, информации о ее зависимости). Я не знаю, как meson это работает, поэтому не могу сказать, как это исправить.

2. Я открыт для использования любой другой альтернативы. это всего лишь официальная книга, подтвержденная gtk-rs ( gtk-rs.org/gtk4-rs/stable/latest/book/hello_world ) рекомендует это. У вас есть другие на примете?

3. Ваша установка сильно отличается от gtk-rust-template проекта, к которому вас направляет эта книга? В частности, я имею в виду ваш корневой meson.build файл, сценарии в build-aux папке, от которой он зависит, и meson.build файлы в подкаталогах, которые он извлекает (данные, po и src): src/meson.build вызывает cargo как custom_target то, что было определено в корневом файле. Есть ли какая-то причина, по которой вы не начали с шаблона, как рекомендовано в книге?

4. Спасибо вам за ваш комментарий. Это было первое, что я сделал. Однако я могу использовать скрипт python только для инициализации проекта. Я не могу использовать flatpac, потому что я не на Linux.

5. Мезон не использует груз по дизайну (это было бы похоже на то, как мезон вызывает cmake или ./configure). В какой-то момент в meson.build была ветка для обработки ящиков (я автор этой серии), но она так и не приземлилась. Использование Мезона с ржавчиной прямо сейчас действительно хорошо работает только для проектов, которые не используют ящики, поскольку основными потребителями этой функции являются проекты C/C с низким уровнем в стеке, которые занимаются ржавчиной, которые не могут или не будут использовать ящики.