[Feature]: Consider Downstream Build Options for Patina Consumers

[os-d]

Feature Overview

edk2 has a unique build infrastructure that defines all toolchain options for consumers of it, which, while creating some pain points, does also unify the build landscape and have fewer odd build configurations come out of the woodwork. Patina does not have any such concept and may be at risk of random platform build options causing unexpected behavior/output.

Solution Overview

Consider how Patina should evangelize build options, this may be:

• nothing, this is like most other build systems you are on your own
• Write up in the md book what recommendations are (runs risk of platforms not noticing)
• Construct something for platforms to consume to define build options
• Something else

At the very least, we should document the decision made here.

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

@makubacki may be interesting to discuss in a future Rust meeting.

[Javagedes]

One option is to write a cli tool that sets all the build flags for someone when building. That way they don't require having to copy our cargo make config file, or their own custom command overrides, which can be annoying.

> cargo install patina
> patina build
> patina test
> patina ...

[makubacki]

@os-d, can you please provide more detail about the ask? What exactly do you mean by "build options" here?

[os-d]

@makubacki , we were having some offline discussions on something that fills an equivalent function as tools_def.template in edk2, i.e. we are somewhat unique as a project that requires other projects to build us not in our repo (most projects get built within the repo they originated in and so use makefiles, etc. there).

If we don't have a standardized set of build options that a platform uses to build with, we are likely to see spurious errors and build failures. I don't know in the Rust world what the best way to do this is, whether build.rs files (which I'm told can be included by a consumer), the tool Joey is suggesting, or something else, but the overall goal is to create a uniform build environment for platforms to minimize noise from inconsistent compiler/linker options.

[Javagedes]

I continue to think my suggestion of having a very small (NOT BUILDTOOLS) wrapper around cargo is a good option. This is also basically what @vineelko suggested a while ago with "xtask".

We could also use the main patina crate as that command line tool.

My suggestion is to basically just change everything that cargo make does to be a subcommand of patina. Then that way when patina consumers attempt to build, our build docs don't say "copy this make file and do these other things", it just says "install patina (cargo install patina) and from then on-out its just "run patina build --arch x64", etc.

[vineelko]

I am not sure if some of the concerns being raised here can be addressed in the below RFC #503