x86 backend-only options passed to GCC

[RossSmyth]

GCC's -m flags stand for "machine", and are backend-specific. For better or worse. This means that passing -m64 is not valid for compilers that target Arm, for example if you are using an aarch64 Linux or Darwin computer.

Places this occurs:

Unity/test/targets/ansi.yml

Line 20 in b9d897b

- "-m64"

Unity/test/targets/ansi.yml

Line 35 in b9d897b

- "-m64"

Unity/test/targets/gcc_64.yml

Line 18 in b9d897b

- "-m64"

Unity/test/targets/gcc_64.yml

Line 34 in b9d897b

- "-m64"

Unity/test/targets/gcc_auto_limits.yml

Line 18 in b9d897b

- "-m64"

Unity/test/targets/gcc_auto_limits.yml

Line 34 in b9d897b

- "-m64"

Unity/test/targets/gcc_manual_math.yml

Line 18 in b9d897b

- "-m64"

Unity/test/targets/gcc_manual_math.yml

Line 34 in b9d897b

- "-m64"

Unity/test/targets/gcc_auto_stdint.yml

Line 18 in b9d897b

- "-m64"

Unity/test/targets/gcc_auto_stdint.yml

Line 47 in b9d897b

- "-m64"

[mvandervoord]

I'm hearing that you feel we should be expanding and renaming our collection of sample project.yml files to better label x86 vs x64 vs arm vs arm64, etc?

[RossSmyth]

All I'm doing it calling rake ci

[RossSmyth]

I use this library at work, and am trying to improve the packaging on nixpkgs
NixOS/nixpkgs#388787

[mvandervoord]

So probably I need to improve documentation too. :)

rake ci isn't a bad place to start, but it doesn't specify what kind of platform you're on. Without being told the platform, it falls back to using gcc for x64, I believe.

You can specify which platform you are using but still run all the suite like this:

rake config:gcc_64 ci

You can also clone any of the yml files and tweak to match your desired settings... they're examples.

You'll notice that some configurations don't run as many tests as others... this is because it's smart enough to not run tests for the features that don't exist... for example, don't run 64-bit asserts if the target isn't supporting them.

Getting back to what I was originally saying, though, this could all get more variations (better arm examples) and better naming.

[RossSmyth]

Ok so your tests are not for Arm then it seems. For packaging the intent is to modify the original as little as possible. So cloning the yaml file to create new configurations is not something I'm going to do. Looking through your "examples", which I would just call your test suite since it is in the tests directory, it seems none of the support GCC or Clang's Arm backend as they all specify -m64.

In general I consider "support" to mean "is tested for." Because in reality, if you don't test something, it can very easily break. So it is hard for me to consider Unity to support being built for anything except x86 since that is all that is tested in CI.

[Letme]

I use Unity to run tests on aarch64 (arm 64), cortex-m3, cortex-m0plus with both Clang and GCC. Not sure what you want to say/claim though.

[Letme]

Keep in mind there is nothing 64bit specific in this library and that unity is usually built along with a project - so shares all the flags. While some warning levels might provide additional warnings, there are no errors. Compiler flags are for users who write tests, but Unity has nothing compiler specific inside.

[RossSmyth]

If you read what I wrote it should be clear.

1. The test suite for Clang and GCC only supports x86.
2. In general when people claim for something to be supported in software, it better be backed with testing.
3. It is hard for me to then claim that such support exists for packaging purposes since it is not tested in CI. Any other platform support is incidental.

I use Unity every day at work. I am very aware of how flexible it is. But without tests, deploying Unity to a packaging repo it is hard for me to claim support for platforms that are untested.

[RossSmyth]

I will disable the tests on all other platforms, but that is quite unfortunate.

[Letme]

I will rephrase. I am not sure I understand the failures in your packaging script - I assume that is where you wanted to add tests and claim they are not supported? Why would it fail in your CI if you provide correct compiler and linker flags - because it does not fail within my projects and in test/targets you also have examples for other targets (some indeed have m64 in linking stage, but that is probably as there were no non-x86 runners available in CI). I assume you want us to change the test/targets/ towards that, but now you are discarding a lot of Unity users with your packaging decision that Unity is not compatible for other platforms.

Maybe the problem is that you use rake and I just use Make and Ceedling (which is kinda rake) for my tasks and I setup my own .yml configurations (ceedling as example) to fit machine type I will run on.

[mvandervoord]

I believe there are some misunderstandings:

The test suite for Clang and GCC only supports x86.

Not at all. The test suite supports many platforms. It defaults to gcc on x86 if you don't tell it to use something else, but that doesn't mean it doesn't support them. ThingamaByte runs this test suite against a large number of target yaml files to help ensure that everything is working fine (this includes a number of ARM platforms using a variety of compilers. As @Letme was explaining, though, the intention is for you to run it against your precise configuration of settings.

In general when people claim for something to be supported in software, it better be backed with testing.

I agree with you, and It is indeed! We're further encouraging you to use your settings to validate that it also works on your tool versions and configurations. We just have no way to guess what those are. :)

It is hard for me to then claim that such support exists for packaging purposes since it is not tested in CI. Any other platform support is incidental.

I agree with this also and for the reasons you're stating. I think this responsibility falls on both of us.

A. It falls on the maintainers of Unity (myself and others) to prove that it works on popular platforms using popular settings. The CI on this project was set up when x86 was overwhelmingly the popular platform and (I believe) was the only option on CircleCI (which is what we started with as a CI engine). I'm reopening this issue because I agree with you, we should update CI to run the ARM suite publicly so everyone can see and validate for themselves.

B. Even with A above, as a project that is making use of a collection of tools that have nearly infinite combinations of settings (I'm looking at you, gcc and clang), I'd highly recommend also running out test suites with your specific settings. It's one thing to say "It works on someone else's machine with their version of gcc, their specific target, their specific flags, etc." It's quite another thing to know that it works for your situation. The only way to do that is to use your own configuration settings.

I will disable the tests on all other platforms, but that is quite unfortunate.

So in summary, I wouldn't do this, if I were you. I'd add an appropriate yml file for each of your targets and actually verify it works. I think you'll be glad you did.

Thanks for chatting this all out and thanks for bringing it up. You're absolutely correct that these tools should have ARM targets as part of their public test suite for all to reference as examples. I appreciate the reminder!

[RossSmyth]

I see, so there is a test suite just not exposed on CI. I am mainly trying to validate it works with nice default for packaging.

I use this library at work. I understand how to use it. I also know it works. I am just trying to validate tests before deploying more to nixpkgs.

Also, running your example rake config:gcc_64 ci fails with a Don't know how to build task 'config:gcc_64'

[mvandervoord]

Whoops. My apologies. I've clearly been working on Ceedling mostly lately.

That should be rake config[gcc_64] ci