Prepare for a Preview release

[ghaith]

With Debugging out of the way and ST functionality more or less complete, I think it's time we create a preview release, maybe version 0.2

We should fix the installation documentation as well as the examples before that
It might also be helpful to fix some still open issues, but this is not urgent since this is just a preview.

I created a label: 0.2 to tag issues we should target.

[r2k-in-the-vortex]

What would it take for that release to include published packages crosscompiled for common architectures? I'm currently struggling to get Rusty built on raspberry and it's really not going easy, the thing is just too slow to handle rust build tools. I'll get it done for myself, but I want Rusty to be an option for OpenPLC users, I think it's not a very good option if they have to rebuild it themselves on all sorts of embedded platforms.

[ghaith]

Is the intention to compile on the raspberry pi or just for the raspberry? The later option works well for the first I'd experiment with a cross compilation using the armv7 target or the aarch64 target. We already build the standard functions with aarch64 using cross compilation as well. Armv7 might be a bit problematic at the moment however because it's 32bit which might make some of the pointer checks behave differently. We need to address platforms with less than 64 bit still.

…

On Sun, 18 Dec 2022, 10:31 r2k-in-the-vortex, ***@***.***> wrote: What would it take for that release to include portable published packages crosscompiled for common architectures? I'm currently struggling to get Rusty built on raspberry and it's really not going easy, the thing is just too slow to handle rust build tools. I'll get it done for myself, but I want Rusty to be an option for OpenPLC users, I think it's not a very good option if they have to rebuild it themselves on all sorts of embedded platforms. — Reply to this email directly, view it on GitHub <#699 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAIRVX3ZDVLGTXACDC2JADWN3DV7ANCNFSM6AAAAAAS7YSY7Y> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[r2k-in-the-vortex]

The intention is to compile structured text with rustyc on raspberry 4(aarch64), because that's how the OpenPLC is built. User sends plaintext ST to runtime over web interface, runtime compiles, links and starts it.

However, I don't want to compile rustyc on pi, even getting rustup installed on pi is a obstacle, takes forever and currently fails. Even if I get it running, any user would have similar difficulties compiling rustyc on embedded platforms. The proper way to do that would be to simply install rustyc from a binary package and have it working without any fuss.

I'll try cross compiling rustyc on my pc and deploying to raspberry, but again, that's not a terribly reasonable way to install software for end users, everything else they can set up on target locally, only requiring internet connection.

[ghaith]

Yes I agree if we can cross compile easily i would add it to the workflow

…

On Mon, 19 Dec 2022, 12:56 r2k-in-the-vortex, ***@***.***> wrote: The intention is to compile structured text with rustyc on raspberry 4(aarch64), because that's how the OpenPLC is built. User sends plaintext ST to runtime over web interface, runtime compiles, links and starts it. However, I don't want to compile rustyc on pi, even getting rustup installed on pi is a obstacle, takes forever and currently fails. Even if I get it running, any user would have similar difficulties compiling rustyc on embedded platforms. The proper way to do that would be to simply install rustyc from a binary package and have it working without any fuss. I'll try cross compiling rustyc on my pc and deploying to raspberry, but again, that's not a terribly reasonable way to install software for end users, everything else they can set up on target locally, only requiring internet connection. — Reply to this email directly, view it on GitHub <#699 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAIRVRSQGJWZ6KHEF6OT5TWOA5ONANCNFSM6AAAAAAS7YSY7Y> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ghaith]

In case you missed it every GitHub action also produces Windows and Linux debug builds we could also add aarch64 if it works and make them release builds

…

On Mon, 19 Dec 2022, 13:19 Ghaith Hachem, ***@***.***> wrote: Yes I agree if we can cross compile easily i would add it to the workflow On Mon, 19 Dec 2022, 12:56 r2k-in-the-vortex, ***@***.***> wrote: > The intention is to compile structured text with rustyc on raspberry > 4(aarch64), because that's how the OpenPLC is built. User sends plaintext > ST to runtime over web interface, runtime compiles, links and starts it. > > However, I don't want to compile rustyc on pi, even getting rustup > installed on pi is a obstacle, takes forever and currently fails. Even if I > get it running, any user would have similar difficulties compiling rustyc > on embedded platforms. The proper way to do that would be to simply install > rustyc from a binary package and have it working without any fuss. > > I'll try cross compiling rustyc on my pc and deploying to raspberry, but > again, that's not a terribly reasonable way to install software for end > users, everything else they can set up on target locally, only requiring > internet connection. > > — > Reply to this email directly, view it on GitHub > <#699 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAIRVRSQGJWZ6KHEF6OT5TWOA5ONANCNFSM6AAAAAAS7YSY7Y> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[r2k-in-the-vortex]

Yes I did miss these, but now I see them. Release artifacts for different arches would be exactly what I would need, then I can just download them and hey presto.

[ghaith]

I did a quick test and i got an error when linking. I'm assuming we also need a aarch64 compiled llvm or the llvmlib part of that. I'll try to play around with that in the coming days, or if you get that running it would be great.
We are btw able to compile on aarch64 for aarch64 as we tried that on an M1 mac, both in docker and native. We just need to fix the linking in cross compilation cases

[r2k-in-the-vortex]

Checked the build artifacts under actions, they can't actually be linked to so easily so that's a difficulty in scripts, but release assets are statics links, I think that's the correct place to store binaries?

As for the linking problem, ran into it, I tried but got nowhere with it and I don't think I fully understand what the root problem is there.

[ghaith]

If you just need a lib to link to I was able to generate one but didn't test how well it works. Only the bin actually failed so compiling with --lib would be enough. If you need a .so file we do this on the standard functions build if you need an example. Keep in mind that you would need some C/C++ entry points when creating libs meant to be used by other languages. I'm currently cross compiling llvm for aarch64 to test it out but that will have to wait till tomorrow.

…

On Mon, 19 Dec 2022, 22:17 r2k-in-the-vortex, ***@***.***> wrote: Checked the build artifacts under actions, they can't actually be linked to so easily so that's a difficulty in scripts, but release assets are statics links, I think that's the correct place to store binaries? As for the linking problem, ran into it, I tried but got nowhere with it and I don't think I fully understand what the root problem is there. — Reply to this email directly, view it on GitHub <#699 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAIRVXV4A3FPABNHSOQGC3WOC7FNANCNFSM6AAAAAAS7YSY7Y> . You are receiving this because you authored the thread.Message ID: ***@***.***>