Add GitHub actions to lint, check dependencies, and run tests for the Rust bindings

[cwtchan]

This probably shouldn't be using the mxl-not-built feature but it does make it easier.

[pac-work]

I have literal 0 knowledge about the GitHub pipelines... @pedro-alves-ferreira, you were yesterday mentioning that you can look at the pipelines - maybe @cwtchan did what you meant already?

By the way, sorry, @cwtchan for already merging the destination of this PR. I hope it will be easy to change the destination directly to the https://github.com/pac-work/mxl/tree/rust-bindings . The branch contents should be the same.

[pedro-alves-ferreira]

@pedro-alves-ferreira, you were yesterday mentioning that you can look at the pipelines

Yes, I'll start working on that on Monday.

[pedro-alves-ferreira]

Thanks for this, @cwtchan! I will try to find some time to test it out later today.

[pedro-alves-ferreira]

@pac-work @cwtchan I'll go over this today and see if we can reuse what the C++ build does, and build the Rust stuff against an installed libmxl + headers.

How do you want to deal with the sign-off of all commits? The only thing I can imagine is to create a branch, do fixup commits on top of that branch, and then, prior to opening a PR to mxl/main, we do a --autosquash. What do you think?

[cwtchan]

@pac-work @cwtchan I'll go over this today and see if we can reuse what the C++ build does, and build the Rust stuff against an installed libmxl + headers.

How do you want to deal with the sign-off of all commits? The only thing I can imagine is to create a branch, do fixup commits on top of that branch, and then, prior to opening a PR to mxl/main, we do a --autosquash. What do you think?

This sounds fine to me.

[pedro-alves-ferreira]

I'm doing it here: https://github.com/bisect-pt/mxl/commits/feature/add-github-actions/
I've already rebased onto main and added the licensing information to all files. It would be appropriate if you both signoff this commit too.
Let me see how far I can get today in terms of the CI stuff. I'll be away for a week starting tomorrow.

[pedro-alves-ferreira]

@pac-work @cwtchan

Here's the status:

I opted for adding steps to the existing build.yml file. The reason is one of the requirements we got was to make sure everything should build off a container defined using the project's Dockerfiles. It doesn't see trivial to do that using packaged git actions. So, what I did was to run cargo (clippy, build and test) in the container.
Let me know what you think and if you have a better alternative. Thanks!

[cwtchan]

@pedro-alves-ferreira the only thing I would ask, is can it not live in a different workflow file?

[pedro-alves-ferreira]

Absolutely. I'm just not sure how to do it, while at the same time reusing the mxl build step that happens before it.
What I've been considering is to change build.rs so that it builds mxl from the ground up using CMake, so we don't care if it's built beforehand. Just like any other external crate. That would simplify things, both for CI and for development. What do you both think?

[pac-work]

How do you want to deal with the sign-off of all commits? The only thing I can imagine is to create a branch, do fixup commits on top of that branch, and then, prior to opening a PR to mxl/main, we do a --autosquash. What do you think?

I do not really have experience with fixup commits. I am OK with that, as long as it keeps the history. Losing history is always something I try to avoid, if for no other reason, then to know who I need to contact if some code is suspicious.

All my commits were signed off - is there anything I should do with them to make this work? I guess a fixup commit for that licensing, to show that we agree with the license?

I briefly read on those fixup commits - so they will get merged to the https://github.com/pac-work/mxl/tree/rust-bindings on top of everything, then I will run rebase with --autosquash (which needs to be done anyway to get it on top of the recent MXL) and that will alter the previous commits which were missing signoffs?

[pedro-alves-ferreira]

Hi. Yes, exactly that. I'll try to sign-off all my commits while I'm in vacation. Enviado de Outlook para Android<https://aka.ms/AAb9ysg>

…

________________________________ From: pac-work ***@***.***> Sent: Wednesday, August 13, 2025 8:06:27 AM To: pac-work/mxl ***@***.***> Cc: Pedro Ferreira ***@***.***>; Mention ***@***.***> Subject: Re: [pac-work/mxl] Add GitHub actions to lint, check dependencies, and run tests for the Rust bindings (PR #5) [https://avatars.githubusercontent.com/u/21257376?s=20&v=4]pac-work left a comment (pac-work/mxl#5)<#5 (comment)> How do you want to deal with the sign-off of all commits? The only thing I can imagine is to create a branch, do fixup commits on top of that branch, and then, prior to opening a PR to mxl/main, we do a --autosquash. What do you think? I do not really have experience with fixup commits. I am OK with that, as long as it keeps the history. Losing history is always something I try to avoid, if for no other reason, then to know who I need to contact if some code is suspicious. All my commits were signed off - is there anything I should do with them? I briefly read on those fixup commits - so they will get merged to the https://github.com/pac-work/mxl/tree/rust-bindings on top of everything, then I will run rebase with --autosquash (which needs to be done anyway to get it on top of the recent MXL) and that will alter the previous commits which were missing signoffs? — Reply to this email directly, view it on GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEZI3QGRSLQ5JYPI6MXN57L3NLPXHAVCNFSM6AAAAACC4I4NL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOBSGQ2DEMZQGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[cwtchan]

Absolutely. I'm just not sure how to do it, while at the same time reusing the mxl build step that happens before it. What I've been considering is to change build.rs so that it builds mxl from the ground up using CMake, so we don't care if it's built beforehand. Just like any other external crate. That would simplify things, both for CI and for development. What do you both think?

I have got something which builds mxl using build.rs but it's a little unique to my situation as I use Nix.
I added some options in some of the CMakeLists to not build the tools nor tests if we find that useful.

[cwtchan]

I've added a PR for compiling the base MXL library when compiling `mxl-sys` here
@pedro-alves-ferreira @pac-work