Creating a build-time configuration file

[hug-dev]

Currently all of our build time configuration happens through --features flags. We have one used for testing, and others for providers. In the future we will inevitably have more build time configuration options there.

I think that for centralization, documentation and ease-of-use purposes it would be nice to have all build time configuration in a single file, build-conf.toml. Yes, exactly as we had before and deleted 🤡

From that file it would be easier to include/exclude providers for example, with nice TOML documentation and links to the documentation. It would be a better location to do that rather than in Cargo.toml. Moreover, we could have build config files in the e2e_tests folders, alongside the runtime config file to make the CI script more readable. An environment variable could indicate the location of the file for build.rs to process.

The negative aspect of this is that it will bring more build time dependencies to parse a TOML file and will make compilation take longer.

[ionut-arm]

Yes, totally agree with this. Especially if we'll start having very specific build-time requirements for different platforms, it's horrible to have to write everythinig on the command line every time (or have a gigantic line in a Bash file).

The negative aspect of this is that it will bring more build time dependencies to parse a TOML file and will make compilation take longer.

May I propose again upstreaming Docker images, so we don't build them on every CI run? 🤡 We'd have to build the service, but not all the dependencies...

Edit: We could even just upstream the one that has all the dependencies for all providers and just not use them all everywhere

[anta5010]

May I propose again upstreaming Docker images, so we don't build them on every CI run? 🤡 We'd have to build the service, but not all the dependencies...

Do we already have an account for uploading docker images? I started looking at upstreaming images while checking how we can run parsec in kata-containers

[ionut-arm]

We do not - I was thinking that much like in crates.io , we could just have personal Arm-related accounts. Then again, maybe there already is a corporate Docker Hub account. And maybe we should call for the creation of a crates.io account.

[ionut-arm]

I'm somewhat concerned about the name of the file. I wouldn't want to call it build-conf.toml so as to not confuse people as to what conf.toml is. Maybe build.toml?

Also, would this build configuration completely replace Rust features, or simply build on top of them? I'm not sure how the choices of what to include would be made without the features, though...

[hug-dev]

Agree with the name build.toml.

For your second point I have seen that the --cfg flag you pass to the compiler from the build script does not affect the dependency resolution, see here. That would mean that people would still have to select the specific --features depending on the provider they want for example (or that we compile in all dependencies by default but that is probably a bad idea).

Then I am not so sure if this is a good idea... We would add one more location where people would have to write configuration 😖 The initial idea was to group all build time configuration to a file instead of the command line.

[ionut-arm]

If I read that correctly, the --cfg thingy would allow some conditional compilation features to be enabled during compilation, which is what we want. We could replace our existing Cargo features with stuff that's enabled with this mechanism, and put all dependencies as mandatory. I think you were saying that code that isn't used anywhere is removed anyway from the binary?

[hug-dev]

put all dependencies as mandatory

We could do that but I think that would be a problem for some people that just want to either install Parsec with only a few providers or for developpers to only test particular providers. For example, the tpm-provider feature has quite a lot of requirements in terms of dependencies (having to install libclang, pkg-config, the TSS stack, etc) that we would impose on all the other features. Also, that would make the compilation take longer and heavier (more to download).

I think you were saying that code that isn't used anywhere is removed anyway from the binary?

Yes I think that part is true and that will be optimised away. So the resulting binary might not be different.

[ionut-arm]

Indeed, that makes sense - maybe it's for the best to just keep it as it is for now, instead of having lots of different points for configuring the system

[hug-dev]

Agree, closing for now until we find a better solution.