Suggestion: take into account the library path from build.rs within slint preview

[abique]

trafficstars

I have a build.rs with:

fn main() {
    let manifest_dir = std::path::PathBuf::from(std::env::var_os("CARGO_MANIFEST_DIR").unwrap());
    let library_paths =
        std::collections::HashMap::from([("icons".to_string(), manifest_dir.join("res/icons"))]);
    let config = slint_build::CompilerConfiguration::new()
        .with_library_paths(library_paths)
        .with_style("fluent-dark".to_string());
    slint_build::compile_with_config("ui/main.slint", config).unwrap();
}

Currently slint preview doesn't show resources from @icons/xxx.svg.

I propose that slint_build generates a file slint_compile_commands.json (or something similar, you get the idea) which will contain all the required information for slint preview to work correctly.

What do you think?

[ogoffart]

The LSP can't compile the rust code from build.rs end interpret env variables and other stuff that build.rs can do.

Wou have to configure it separately. Eg: https://slint.dev/releases/1.4.1/docs/slint/src/language/syntax/modules#component-libraries

[abique]

This is understood, but when I compile my rust code, this could generate the slint compile commands. So I need to build the app once, then the slint preview will know.

[tronical]

Related also to #267 - if it were declared in a separate file both could pick it up.

[abique]

Related also to #267 - if it were declared in a separate file both could pick it up.

You may end up with similar complexity as cmake-presets.

[tronical]

I'm uncertain about keeping this suggestion open in light of #267. I suppose it would be possible that build.rs creates some kind of life that somehow the live-preview "fishes" out of the sea of the target directory, but I don't think that's generally a good idea. I'd rather if the information is stored elsewhere.

I've tagged this enhancement in the live-preview, but leave will up to @hunger and @ogoffart whether to leave this open or close it as not planned.

[abique]

Then you'll need to deprecate the settings in build.rs.

It isn't good to have to specify the same information in two different places. So as long as build.rs is a place in which you can feed configuration, the file has to be generated by build.rs.

Also build.rs will have the maximum amount of information available while your suggested configuration file will be restrained to itself.

[ogoffart]

Yes true, ideally we should have a config file that both the preview and the build.rs can read. So closing this in favor of #267

build.rs shouldn't really generate files outside of the target directory. and the preview don't have access to the target directory.