Allow specifying paths for @library imports

[jpnurmi]

This PR is a revised version of #3523 that drops everything related to Cargo and NPM, and instead allows manually specifying library paths in the compiler config:

// build.rs
use std::{collections::HashMap, env, path::PathBuf};

fn main() {
    let manifest_dir = PathBuf::from(env::var_os("CARGO_MANIFEST_DIR").unwrap());
    let library_paths = HashMap::from([
        (
            "libfile.slint".to_string(),
            manifest_dir.join("third_party/libfoo/ui/lib.slint"),
        ),
        (
            "libdir".to_string(),
            manifest_dir.join("third_party/libbar/ui/"),
        ),
    ]);
    slint_build::compile_with_config(
        "ui/main.slint",
        slint_build::CompilerConfiguration::new().with_library_paths(library_paths),
    )
    .unwrap();
}

Import types from the libraries:

import { Foo } from "@libfile.slint";
import { Bar } from "@libdir/components.slint";

export component MyApp inherits Window {
    Foo {}
    Bar {}
}

[tronical]

Looks overall good to me! I think the error handling could be tweaked a little, but otherwise I love it.

Two other missing things I can think of:

• An entry in the ChangeLog
• Documentation in modules.md (could be done separately though)

[tronical]

Ah, but if the import is @some-library/some_file.slint the error message is going to call the entire string a library, when there are in fact two error cases:

1. some-library could not be found (missing in library search path)
2. Within some-library the file some_file.slint could not be found.

[jpnurmi]

Current status:

Import	Library path	Error
@libdir	libdir=/path/to/lib	Error reading requested import "/path/to/lib": Is a directory (os error 21)
@libdir/unknown.slint	libdir=/path/to/lib	Cannot find requested import "@libdir/unknown.slint" in the library search path
@libfile/unknown.slint	libfile=/path/to/lib.slint	Cannot find requested import "@libfile/unknown.slint" in the library search path
@unknown	N/A	Cannot find requested import "@unknown" in the library search path
@unknown/lib.slint	N/A	Cannot find requested import "@unknown/lib.slint" in the library search path

The second and third could be better.

[tronical]

Current status:

Looks good to me. This makes a clear distinction at least between the library search path and regular includes.

[tronical]

I think this is the way to go. This is a very good incremental step to me, and there's time for docs. I'd love to hear what the others are thinking, but IMO this is good to go.

[tronical]

(please rebase once to get rid of the merge commit and the conflicts - we normally do rebases instead of merge, so no worries there :)

[jpnurmi]

I didn't include the docs from #3523 because they were so centered around the Cargo and NPM integration, which was left out of this PR. :)

[ogoffart]

I think this could be merged as is, but still feel it is lacking a bunch of things:

Documentation: there seems to be almost nothing, but the concept of @library should be explained in the docs with help on how to pass these library path.

The slint-viewer also need a way to set the library path through command line argument. Currently there is -I for the include path, but it should also support something like -I library=/path/to/library or some other --lib library=/path/to/library
And this should be documented in the viewer docs

Same for slint-compiler (so it can be exposed in C++)

Maybe the documention of rust can make an example where a crate is taken as a build_dependency and do

pub fn slint_path() -> &str { env!("CARGO_MANIFEST_PATH/index.slint") }

[jpnurmi]

I've added an example to CompilerConfiguration::with_library_paths() docs and made it possible to pass library paths from the CLI. How do you like -Lexample=/path/to/lib?

[ogoffart]

This is not really what i had in mind.
I was thinking that the code that use CARGO_MANIFEST_DIR would be in a build-dependency (eg, coop_widget uploaded to crates.io)
but that work too.

[jpnurmi]

I have somewhat mixed feelings about teaching users to wire up Cargo dependencies manually if the end goal is to make it automatic once the issues with compiling libraries have been sorted out. :)

[ogoffart]

Ok, i understand. Just leave it like this then.

[ogoffart]

How do you like -Lexample=/path/to/lib?

I like it. At least seems reasonable and can't think of anything better.

[jpnurmi]

Rebased and squashed the fixup commits

[FloVanGH]

@jpnurmi this is the branch where I make usage of the @ https://codeberg.org/flovansl/co_sl/src/branch/coop_widgets/lib-import

[jpnurmi]

@jpnurmi this is the branch where I make usage of the @ https://codeberg.org/flovansl/co_sl/src/branch/coop_widgets/lib-import

Cool, thanks for giving it a try! A helper function for the import paths is quite nice to avoid an awkward empty lib.rs that I had in some earlier attempt. :)

[FloVanGH]

@jpnurmi this is the branch where I make usage of the @ https://codeberg.org/flovansl/co_sl/src/branch/coop_widgets/lib-import

Cool, thanks for giving it a try! A helper function for the import paths is quite nice to avoid an awkward empty lib.rs that I had in some earlier attempt. :)

Thank you for implementing it ;-) . I definitely a good progress for the lib imports :-). I like it.