Basic support for TI Arm Clang toolchain - #11421

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 68.79%. Comparing base (675b47b) to head (82e9dca).

❗ Current head 82e9dca differs from pull request most recent head fd626e3. Consider uploading reports for the commit fd626e3 to get more accurate results

@@            Coverage Diff             @@
##           master   #11421      +/-   ##
==========================================
- Coverage   70.43%   68.79%   -1.65%     
==========================================
  Files         219      207      -12     
  Lines       48781    45332    -3449     
  Branches    11606     9378    -2228     
==========================================
- Hits        34359    31185    -3174     
+ Misses      11980    11751     -229     
+ Partials     2442     2396      -46     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Bumping with a rebase against current master. Anything needed from me?

Either that or via a custom subclass. ;)

Is this something that users will need to distinguish between TI arm clang vs regular clang using cc.get_linker_id()?

Have you got any strong leanings toward a custom subclass for a cleaner implementation, or is this OK as is?

I think embedded compilation is specific enough that nobody will really be compiling a piece of code with two different embedded linkers. In the case of tests, I expect people would use meson.is_cross_build() to adjust build logic.

Have you got any strong leanings toward a custom subclass for a cleaner implementation, or is this OK as is?

Not really. I just mentioned it for the sake of argument. I am not sure whether it matters or doesn't matter.

Bah, the more I think about it the more "you must specify these options" feels like a lazy hack fix, especially since I made it work "properly" for the TI CGT compiler. I'll add a TiLLVMDynamicLinker with ID ld.ti and do it right.

Although, as I think a little more - is there any worth to making LLVMDynamicLinker have a function such as supports_argument, which is then extended to gate --no-undefined and --as-needed in addition to --allow-shlib-undefined? I initially didn't consider it because I feel like it might secretly hide any silly bugs with flags (eg: misspelled), especially since those flags are usually pretty specific for those that use them.

Alright, I'm happy with this flag detection now - no modifications needed to any meson.build files, and supports any future compilers missing these standard flags. As discussed before, I'm fine with not having a special linker ID for TI Arm Clang, so this is ready to merge if you're happy with it!

@eli-schwartz what's the status on this PR? Seems like it might've just been forgotten.

Rebased to latest master, seeing C6000 support got merged I hope this one can as well! (pending test runs)

Sorry for the bump, is there anything I can do to help move this along? If there are missing tests that might make it easier from your end, additional documentation etc.

Sorry for the delay.

Thanks for bumping it @mon

Thank you so much!