In D7223#152214, @mat wrote:

It's missing some error checking, if won't say anything if I do USE_GCC= 4.9:foobar

• used GCC instead of gcc in comments
• only add to RUN_DEPENDS and BUILD_DEPENDS by default.

In D7223#152105, @gerald wrote:

Thanks for doing this! I have been on medical leave for most of this
months and am still not fully up and running, so would like to defer the
final review to a different (ports) committer or portmgr, but (a) this looks
fine in principle and (b) some specific comments below.

When this goes in, feel free to add Approved by: gerald in addition to that
of the other reviewer(s).

1. Is there any practical need (example?) for the use of TEST_DEPENDS?

I cannot imagine any, but may be missing something, But, if there is none,
let's omit this?

While I can't think of any current port requiring this, I can imagine it to be useful for any kind of testing of toolkits/toolchains that are used at compile-time and where testing involves compiling things against them. While I admit it's a bit of an edge case, I have seen some (admittedly obscure) library headers not compile correctly using clang++ or g++, respectively. Testing this might be useful. However, I'd agree to not adding GCC to TEST_DEPENDS by default.

added aliases for build, run and test as requested by @mat

In D7223#150739, @mat wrote:

I assume USE_GCC= yes:build works, maybe USE_GCC= build could be used instead.

In D7145#150327, @editor_callfortesting.org wrote:

I can't help but notice that there is a /usr/share/firmware directory.

Should this simply be used?

original patch was missing build_args+=-DCSM_ENABLE=TRUE

TBH, we should also bump the port version here.

tbh, I'd argue for a -csm port, and make no csm the default - but I guess this should be discussed. But this would also be fine for me.