Static vendored builds PoC

[opeik]

Hi there, building libcec is a massive pain in the ass (as you probably know), so I opted to create a pipeline for building libcec staticly and generating bindgen bindings so they can be committed. It might be useful for you. The result is zero friction using libcec from Rust, much nicer than dealing with dynamic libraries in my opinion.

• Workflow
• cec_sys
• cec_bindgen

Related to ssalonen/libcec-sys#45.

[ssalonen]

This looks amazing! I can see you have also done the enum bindgen generation in rust, compared to the python approach I had come up with. Very good - will be easier to integrate

Overall on the surface this looks something that I would like to integrate here

[opeik]

Thanks, a lot of trial and error went into making it work. I'd be thrilled to see it upstreamed.

[opeik]

I've merged libcec-vendor into owl so there's less repos for me maintain and updated the links in my original post.

[ssalonen]

Thank you @opeik so much! I have now adapted your work here in libcec-sys. I can see how you have probably worked on this quite some time, it took me still considerable effort integrate this.

The static builds happen in my libcec fork https://github.com/ssalonen/libcec-static-builds/releases/tag/libcec-v6.0.2 . For now only for the same architectures that you had implemented. I have also kept option for vendored build, as well as dynamic linking. Things should fallback to static when dynamic linking fails. Exact logic is explained in libcec-sys README https://github.com/ssalonen/libcec-sys/blob/master/README.md.

I have kept to support for other architectures (like raspberry pi) and different libcec versions, so there's many variations of the low level libcec-sys bindings https://github.com/ssalonen/libcec-sys/tree/master/src.

Binding generation is configured as a separate manually-triggered job at https://github.com/ssalonen/libcec-sys/actions/workflows/bindgen.yml . I have opted not to take nix into use as I was not using that before and I would not have known how well it works with the other platforms/architectures.

This is now all released in cec-rs version 11, and libcec-sys version 7. There are some API changes as well which forced to bump up major version.

[opeik]

Love to see it, thanks! Hopefully wasn't too painful for you lol.

[ssalonen]

@opeik I experimented a bit on more rigorous way to build static cec and seems like only few changes are needed to CMake files, sharing here https://github.com/ssalonen/libcec-static-builds/tree/static-builds-minimal-changes-upstream .

By default, libcec builds static always on windows (target libcec-static) but not on other platforms. It is easy to make the change to build it on all platforms. To speed up the build, I disabled building of command line clients etc. Further speed up would be to disable dynamic building of cec

I will probably clean that one and switch to this to have more understandable fork of libcec. I noticed you had done many changes on cmake level.. I was not able to follow those, knowing only cmake superficially.

Another question: is it so that p8-platform.a is unnecessary? I noticed you packaged it up in your builds in github. To my understanding static build of libcec includes also the pieces from p8-platform.

[opeik]

@ssalonen

I will probably clean that one and switch to this to have more understandable fork of libcec. I noticed you had done many changes on cmake level.. I was not able to follow those, knowing only cmake superficially.

It's been a hot minute, IIRC I had to modify the CMake files to spit out statically linked libraries on all platforms.

Another question: is it so that p8-platform.a is unnecessary? I noticed you packaged it up in your builds in github. To my understanding static build of libcec includes also the pieces from p8-platform.

That's a good point, and you're probably right. I think I threw it in there just in case—I was pretty frustrated after getting the build to coöperate.