Unfortunately I have to change the working directory of the application which I was trying this on and found that the reloader blows up because it is assuming the target is relative to current working directory. The initial thought was to do something based on env! and/or related items but I don't believe I can get those passed into the proc-macro attributes properly. (Or I just suck with that bit of meta-programming, very possible.. :) ) So, I was wondering if it would be viable to do something which delays the reloader setup till entry into main such that I could then tell it, at runtime, use xyz path as the root path rather than assuming things are relative.

If I could set it in main, then I can use the env! macro and fiddle the compile time result to point to the correct place, i.e. a rooted path from the manifest directory down to the containing workspace directory where the 'target' folder lives. Or, I'd love a pointer on how to build that path such that the proc macro attribute would accept it correctly. I.e. I need: env!("CARGO_MANIFEST_DIR") + "/../../" to get the correct base path. But, of course that could change if I'm using the lib as a pulled crate rather than a part of the larger project (which is an eventual desire).

Thoughts and suggestions very welcome.

While retrofiring my project to use hot-lib-reloader-rs I ran into a very confusing issue, the notification from wait_for_about_to_reload never came back to me. I spent 2 hours comparing my project to the sample, refactoring, debugging, etc.

It turns out that if you don't call into any function in your hot reload API consistently (or at least once?) you don't get any notification.

My use case involves waiting for a reload, and then doing a bunch of work. I was not calling any API before the notification.

Once I created an empty API that I called in my message loop everything started working.

I'm filing this to suggest a documentation change to explain how\when the listening occurs.

All the examples provided work except the bevy one,

LINK : fatal error LNK1104: can't open file '.\hot-lib-reloader-rs\examples\bevy\target\debug\deps\systems.dll

I'm trying to hide some of the moving parts by creating the exported, no_mangle'd functions in a macro (exposed from a library) but when I attempt to use it in my reloadable lib, the hot_functions_from_file function doesn't find them.

// mod file1
#[macro_export]
macro_rules! make_exports {
  #[no_mangle]
  pub fn f() -> i32 { 42 }
}

// mod file2
make_exports!();

// main
mod hot_lib {
  hot_functions_from_file("file2/src/lib.rs");
}

fn main() {
  hot_lib::f(); // function not found in `hot_lib`
}

I'm writing a sort of game engine and I would like to be able to only reload game code on request (say, when a user presses Cmd+R). Is this currently possible with the library? I couldn't figure it out.

Thanks!

If I understood correctly, the HotModule will parse and expose as hot-reloadable all public no_mangle functions, but I was wondering if marking systems functions as #[no_mangle] may impact production performance, since AFAIK Rust compiler won't be able to fully otimize those functions.

It's possible somehow to only mark #[no_mangle] on hot-reload builds?

By coincidence I made my own hot-reloading test just a few weeks ago when I read fasterthanli's article However I find that, my setup. Is a tad bit less of a hassle to set-up. I also watch for file changes & use libloading. However I use: cargo-watch -x "build -Z unstable-options --out-dir ./plugins" Then simply watch the directory for Event::Write events.

I only need to specify the plugin directory, which I find less of a hassle to write compared to

hot_lib_reloader::define_lib_reloader! {
    unsafe MyLibLoader {
        lib_name: "lib",
        source_files: ["path/to/lib.rs"]
    }
}

For each library.

However you need to check the function signature in the source file, and must therefore know the source location. Except the source location embedded in the library if it's a debug build so you may extract it from there. I'm sure there's a library that can extract it easily, but I wouldn't the name on top of my head. (maybe symbolic-debuginfo?)

If you're interested, here's my main method for my reload test. ( Probably adopted from fasterthanli, I can't remember )

use std::{error::Error, path::Path};

// use hotwatch::{Event, Hotwatch}; // Non blocking
use hotwatch::blocking::Hotwatch;   //     Blocking
use libloading::{Library, Symbol};

static PLUGINS_LIBRARY_PATH: &str = "."; // Relative to the process' current working directory
fn main() -> Result<(), Box<dyn Error>> {
    let mut hotwatch = Hotwatch::new().expect("hotwatch failed to initialize!");

    hotwatch.watch(PLUGINS_LIBRARY_PATH, |event| {
        if let hotwatch::Event::Write(path) = event {
            if path.extension() == Some("so".as_ref()) {load_and_print(&path).expect("Error loading so file.");}
        }

        hotwatch::blocking::Flow::Continue
    })?;
    hotwatch.run();
    Ok(())
}

fn load_and_print(path: &Path) -> Result<(), libloading::Error> {
    unsafe {
        let lib = Library::new(path)?;
        let greet: Symbol<unsafe extern "C" fn(name: String)> = lib.get(b"greet")?;
        greet("reloading".to_string());
    }

    Ok(())
}

On macos the application crashes after some reloads with EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)).

This is a known issue see for example:

• https://developer.apple.com/forums/thread/696460
• https://developer.apple.com/documentation/security/updating_mac_software

In order to deal with this we need to make sure the copied dylibs get codesigned.

The hot_module attribute macro (via hot_functions_from_file!("path/to/file.rs")) and the define_lib_reloader!(...) macro allow specifying Rust source files from which public #[no_mangle] functions are discovered and for which hot-reloadable proxy functions are created.

So far, both macros expected file relative paths, i.e. paths relative to the file where the macro was defined. So, for example:

├── Cargo.toml
└── src
│   └── main.rs    <- hot_functions_from_file!("../lib/src/lib.rs");
└── lib
    ├── Cargo.toml
    └── src
        └── lib.rs 

Code for this is here: https://github.com/rksm/hot-lib-reloader-rs/blob/cb016a03c68ea2fb2176b683ff466d8bdb8f94e0/macro/src/util.rs

The reasoning behind it was that it might be more intuitive and easier to reason about with larger code bases but there are two problems that requiring a relative path created:

1. We need Rust nightly to use the proc_macro::Span feature to lookup the path of the file in which the macro was declared
2. rust-analyzer fails to expand the macro and cannot give code completion

Thinking about it again, requiring that the path of the files to be relative to the project root is not so bad and will solve both of the problems above. But it means that we need to break the interface. For this reason this change requires a version bump to v0.6.

So` instead of the above, the following will be expected:

├── Cargo.toml
└── src
│   └── main.rs    <- hot_functions_from_file!("lib/src/lib.rs");
└── lib
    ├── Cargo.toml
    └── src
        └── lib.rs 

I used a convoluted half-baked incorrect ref counting scheme for access to symbols while not needing to mutex lock the lib loader during a call (so that recursive calls work)

This is much better addressed with a RwLock that.

This cleans up both the __lib_loader() and __lib_notifier() accessors. It should also fix spurious crashes during hot updates that were likely caused by symbols actually being used (b/c the prev solution wasn't really thread safe).

Added support for getting lib reload events. Inside a hot_module, the following creates a function that can be used to subscribe:

#[lib_change_subscription]
pub fn subscribe() -> std::sync::mpsc::Receiver<hot_lib_reloader::ChangedEvent> {}

I've been experimenting with the following Iced sample code, but it keeps crashing at every lib reload. I can't figure out if I'm mistaking something or if it's due to a hot-lib-reloader-rs' issue, can you please help me out?

I tested the attached code both on Windows 10 and Arch Linux, with rustc version 1.65.0 and 1.67.0-nightly, and I attempted also using cargo run --features iced/glow with no luck.

commands:
  bin: |
    cargo run
  lib: |
      cargo watch -w lib -x 'build -p lib'

bin

[workspace]
members = ["lib"]

[package]
name = "bin"
version = "0.1.0"
edition = "2021"

[dependencies]
hot-lib-reloader = "0.6.4"
iced = "0.5.2"
lib = { path = "lib" }

#[hot_lib_reloader::hot_module(dylib = "lib")]
mod hot_lib {
    use iced::{Element, Theme};
    pub use lib::*;
    hot_functions_from_file!("lib/src/lib.rs");
}

use hot_lib::*;
use iced::{Element, Sandbox, Settings, Theme};

fn main() -> iced::Result {
    App::run(Settings::default())
}

#[derive(Debug, Default)]
struct App {
    state: State,
}

impl Sandbox for App {
    type Message = Message;

    fn new() -> Self {
        Self::default()
    }

    fn title(&self) -> String {
        title()
    }

    fn update(&mut self, message: Message) {
        update(&mut self.state, message)
    }

    fn view(&self) -> Element<Message> {
        view(&self.state)
    }

    fn theme(&self) -> Theme {
        theme(&self.state)
    }
}

lib

[package]
name = "lib"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["rlib", "dylib"]

[dependencies]
iced = "0.5.2"

use iced::widget::{
    button, column, horizontal_rule, horizontal_space, radio, row, text, vertical_space,
};
use iced::{Alignment, Element, Length, Theme};

#[derive(Debug)]
pub struct State {
    text_size: u16,
    theme: Theme,
}

impl Default for State {
    fn default() -> Self {
        Self {
            text_size: 100,
            theme: Theme::default(),
        }
    }
}

#[derive(Debug, PartialEq, Eq, Clone, Copy)]
pub enum ThemeType {
    Light,
    Dark,
}

#[derive(Debug, Clone)]
pub enum Message {
    ThemeChanged(ThemeType),
    IncrementTextSizePressed,
    DecrementTextSizePressed,
}

#[no_mangle]
pub fn title() -> String {
    String::from("Hello World - HotIce")
}

#[no_mangle]
pub fn update(state: &mut State, message: Message) {
    let size_change = 10;
    match message {
        Message::ThemeChanged(theme) => {
            state.theme = match theme {
                ThemeType::Light => Theme::Light,
                ThemeType::Dark => Theme::Dark,
            }
        }
        Message::IncrementTextSizePressed => {
            if state.text_size <= 200 - size_change {
                state.text_size += size_change;
            }
        }
        Message::DecrementTextSizePressed => {
            if state.text_size >= size_change {
                state.text_size -= size_change;
            }
        }
    }
}

#[no_mangle]
pub fn view(state: &State) -> Element<Message> {
    let choose_theme = [ThemeType::Light, ThemeType::Dark].into_iter().fold(
        column![text("Choose a theme:")].spacing(10),
        |column, theme| {
            column.push(radio(
                format!("{:?}", theme),
                theme,
                Some(match state.theme {
                    Theme::Light => ThemeType::Light,
                    Theme::Dark => ThemeType::Dark,
                    Theme::Custom { .. } => panic!(),
                }),
                Message::ThemeChanged,
            ))
        },
    );

    column![
        row![choose_theme, horizontal_space(Length::Fill)],
        horizontal_rule(20),
        vertical_space(Length::Fill),
        text("zHello, world!").size(state.text_size),
        vertical_space(Length::Fill),
        row![
            button("Increment Text Size").on_press(Message::IncrementTextSizePressed),
            button("Decrement Text Size").on_press(Message::DecrementTextSizePressed),
        ]
        .spacing(20)
    ]
    .spacing(20)
    .padding(20)
    .align_items(Alignment::Center)
    .into()
}

#[no_mangle]
pub fn theme(state: &State) -> Theme {
    state.theme.clone()
}

The hot_functions_from_file! macro is very helpful, but it only works on single files (which most non-trivial projects grow out of quite quickly). If a user wants to break up their project into multiple files for manageability, their options are:

• Redefine the hot-reloaded library's whole API either in a single file for hot_functions_from_file! to pick up or directly in the hot_module
• Multiple calls to hot_functions_from_file! for every file in the project

Both of these things are rather clumsy and would be unnecessary if hot_functions_from_file! didn't only work on single files. I took a look at the package source to see if there's any technical limitation preventing the macro from working on folders too but as far as I can tell, the only thing is that if a user uses the ignore_no_mangle option there is the possibility of duplicate function names in different files.

Proposal

Provide a new hot_functions_from_folder! or hot_functions_from_crate! macro that recursively pulls public no-mangled function definitions from a provided folder or crate path. Unlike hot_functions_from_file! it will not take an ignore_no_mangle argument, so that the function names/symbols are known to be unique.

I don't mind implementing it myself if you're good with this but that would have to be over the weekend.

I was trying to use this library for a project that uses syscalls, libc, nix etc (e.g. shared memory, mutex). also, tokio async and unsafe are used across my project. It threw segmentation fault with hot reloading. i am looking some guidance on suitability of using this library.

Currently impl methods are not supported, only plain functions. impl methods can be declared as no mangle as well so there is no reason to not support them. This will require some thinking about invocation: method(&self, arg) will work but self.method(arg) not without some work...

Running on Ubuntu 20.04

When testing out the bevy example, if I add commands to the parameters for player_movement_system then the application seg faults. This happens for any change to the system params I have tested. This may be a fundamental limitation with these techniques though.