Cargo only builds

[teburd]

I suppose its a big ask, but can the build.rs build ecal when its not found perhaps for the target arch? The work I do today targets armv7, aarch64, and x86_64... setting up the build envs with a C++ dep like ecal is a serious hassle compared to cargo build.

[rex-schilasky]

Could these docker images or the provided archs be helpful for you ? https://github.com/Blutkoete/docker-ecal

[photex]

@BFrog It's not impossible but in practice it was a bit of a challenge and a little time consuming.

I'm definitely open to make it a feature gated build step though. Cross compilation is where some of the hairy parts pop up (because of the need for a host native protobuf compiler).

We have a cmake toolchain used for cross compilation that works without docker that we use to target aarch64. With the right environment that would work here I think.

[teburd]

I guess what I'm really saying with this is, ecal should be as easy to use as any other rust crate in the ideal scenario.

That means that you don't need to think about cmake, gcc, and whatever other deps might be needed. You add eCal to your Cargo.toml, and your done. That's the ideal scenario.

[photex]

I understand. I initiated similar stuff for sqlite and lmdb crates a while back.

For eCAL that is easy to achieve when you're building for the host platform.

When cross compiling you have to find some way to get a host protoc to work with.

In addition to this depending on what other crates you link with, you may have some trouble with the protobuf dependency.

In our case, when building for Linux, we have to use whatever version of protobuf tensorflow is linked with. Windows generally works fine.

So adding this to the build script for the initial goal of making it work for the host is doable and probably not much work honestly. We can even add bindgen there I think.

But if you're cross compiling I'm not sure what needs to happen to make that work.

[teburd]

I think that's a fair assessment! In a cross compiling scenario maybe the best that can be done is documenting some env vars that should be set to point things at the right place, it looks like it's already there in the build.rs where to look for the lib and such.