Add source built serial monitor rust

[MementoRC]

/claim #2

[algora-pbc]

💵 To receive payouts, sign up on Algora, link your Github account and connect with Stripe.

[MementoRC]

@wolfv I am a bit new to this process and focused on preparing the conda-forge recipe under:
conda-forge/staged-recipes#28473
This enables making sure that the recipe builds for all staged archs - at the time or writing, linux/osx are green, win is straggling (you don't say!)

[wolfv]

Wow! I'll fix up the stdlib thing in this repo tomorrow!

[MementoRC]

Cool, is it that there are no defaults? Should I no rather update with a variant_config.yaml, this way it's clean

[hacknus]

I'm a bit confused to what you want to build - the way I see it, this does not create any bundles for the serial monitor, just the binary, right?

and how did you select the third-party crates that you implemented a recipe for? are they required at all and why did you not implement all of them (for example egui-logger is not built separately here)?

[MementoRC]

I'm a bit confused to what you want to build - the way I see it, this does not create any bundles for the serial monitor, just the binary, right?

and how did you select the third-party crates that you implemented a recipe for? are they required at all and why did you not implement all of them (for example egui-logger is not built separately here)?

The primary reason to add the extra builds was that they are pulled-in as git: which does not fix the version of the source and thus could create issues with reproducing the build at a later time.
In fact most of these are for compile/test purpose and only archive the source as a conda-forge package, this will help track the version updates

Keep in mind also that I am not an expert in conda-forge packages, this is just the way I understand it. The problem I see with binary distribution is that it is possible that they break for a particular conda-forge environment. When packages are built from source they should more likely to conform to any conda-forge environments.

[MementoRC]

The issue with osx-arm64 is that several SDK are found, which apple-sys can't handle. The issue with osx-64 is a bit puzzling, it seems to install SDK 14.5, but then complains that it can't be installed? Testing on conda-staged

[MementoRC]

@hacknus In fact, do you mind updating your Cargo.toml for fetching released/tagged versions of the 3 additional packages? We would only keep keepawake-rs as it provides an installable. Let's wait for @wolfv feedback as to these approaches

@wolfv My understanding was that you wanted the recipe on conda-staged (where I initially PR'd) - how would we proceed, do you have a preferential channel into conda-forge, thus I should close the conda-staged PR?

So many questions ... and it's at that moment that they truly understood why the nickname is Claire's Monster

[hacknus]

@hacknus In fact, do you mind updating your Cargo.toml for fetching released/tagged versions of the 3 additional packages? We would only keep keepawake-rs as it provides an installable. Let's wait for @wolfv feedback as to these approaches

I see, makes sense. I can look into it. But I still do not understand why you do not bundle the serial monitor, you only build the binary. If the versions would be fixed and no dependencies would get pulled from git, then #4 would be sufficient?

[MementoRC]

I see, makes sense. I can look into it. But I still do not understand why you do not bundle the serial monitor, you only build the binary. If the versions would be fixed and no dependencies would get pulled from git, then #4 would be sufficient?

From my experience, I do not think that conda-forge would be favorable to bundled binaries, but @wolfv should be addressing that part when he reviews the 2 submissions. I have only ever built source-based conda packages, so that's what I proposed here.

A more concerning issue that is likely related to the bundling is: "How do you bundle for OSX". The issues that I am encountering here is that conda uses SDKROOT to point to the minimal SDK version to deploy for, but apple-sys looks for the latest and fails when it finds another SDK version. The way I passed the build on conda is by overriding the CONDA_BUILD_SDK, the PATH and the CPATH, but I suspect I can only deploy on SDK >15.2

I am currently looking into repackaging a patched apple-bindgen and apple-sys specifically for conda-forge, but I don't know too much about OSX SDKs and if that's the best way to go about it

[hacknus]

I see, makes sense. I can look into it. But I still do not understand why you do not bundle the serial monitor, you only build the binary. If the versions would be fixed and no dependencies would get pulled from git, then #4 would be sufficient?

From my experience, I do not think that conda-forge would be favorable to bundled binaries, but @wolfv should be addressing that part when he reviews the 2 submissions. I have only ever built source-based conda packages, so that's what I proposed here.

I see, yes. Serial Monitor was built to run as a bundled application, since it is a GUI. But of course you could also launch it from the command line..

A more concerning issue that is likely related to the bundling is: "How do you bundle for OSX". The issues that I am encountering here is that conda uses SDKROOT to point to the minimal SDK version to deploy for, but apple-sys looks for the latest and fails when it finds another SDK version. The way I passed the build on conda is by overriding the CONDA_BUILD_SDK, the PATH and the CPATH, but I suspect I can only deploy on SDK >15.2

I am currently looking into repackaging a patched apple-bindgen and apple-sys specifically for conda-forge, but I don't know too much about OSX SDKs and if that's the best way to go about it

Interesting, I have not had a problem with that using cargo bundle and compiling for different machines (e.g. github runners) but I never used conda like this before..

[hacknus]

v0.3.1 is now only depending on releases of dependencies.

[MementoRC]

I see, yes. Serial Monitor was built to run as a bundled application, since it is a GUI. But of course you could also launch it from the command line..

The end-user will likely use it as a GUI, within its conda environment, which would install the appropriate libs and resolve potential conflicts, i think that's a key feature for conda and the way the packages are built must be controlled (at least that's my understanding)

Interesting, I have not had a problem with that using cargo bundle and compiling for different machines (e.g. github runners) but I never used conda like this before..

Right, I have a bit of a hard time getting the gist of it, cargo and conda may be overlapping in what they're trying to achieve, I had similar misunderstandings when working on clojure with its maven framework

[MementoRC]

@hacknus Thank you, the recipe is cleaner now. I am still working on that OSX SDK issue on the conda-staged recipe (i'd rather have tons of commits on that one than here!).

It would be great if you were interested in helping maintaining this recipe, I would focus on the conda maintenance and you'd be the expert on the real meat of the package, as well as Rust, of which I know very little

(Assuming, of course, that @wolfv selects it! ;p)

[hacknus]

It would be great if you were interested in helping maintaining this recipe, I would focus on the conda maintenance and you'd be the expert on the real meat of the package, as well as Rust, of which I know very little

I'll continue to maintain serial-monitor-rust, if you have any troubles that should be adapted on that side you can open an issue there and I'll look into it.

[hacknus]

Please update serial-monitor-rust to 0.3.2, 0.3.1 has a major bug.

[MementoRC]

Finally ... conda-forge still not working though, oddly apple-sys there is a real pain, whereas here is goes through just with BINDGEN

[hacknus]

FYI, the whole thing with pulling the git-repos of the dependencies is not necessary anyways, since the specific commits are locked in the cargo.lock file and cargo build will not fetch the latest updates unless you would run cargo update. (for the latest release of serial-monitor-rust a new git-repo had to be linked again)