Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gcc flags don't work when using ceedling test:* #882

Open
lafonso-gnrc opened this issue Apr 24, 2024 · 12 comments
Open

gcc flags don't work when using ceedling test:* #882

lafonso-gnrc opened this issue Apr 24, 2024 · 12 comments

Comments

@lafonso-gnrc
Copy link

Hello,

To give context, I have a set of unit tests where one function was missing the return statement.

Somehow this passes in unit testing but it fails when running gcov (as in, it runs gcov fine but reports failures) which is weird. I'd expect both to behave the same but that's the main issue I have now.

Regardless, I decided to turn on the plugin warnings_report to be easier to check and add the flags

:flags:
  :release:
    :compile:
      :*:
        - -std=c99
        - -Wall
        - -Werror=return-type
        #- -Werror 
  :test:
    :compile:
      :*:
        - -std=c99
        - -Wall
        - -Werror=return-type
        #- -Werror
  :gcov:
      :compile:  
        :*:
          - -std=c99
          - -Wall
          - -Werror=return-type

So now I at least have gcov with the same flags, although I still get the different behaviours.
And it throws errors when it's missing return statements, good enough.

But, it doesn't work when doing ceedling clobber test:* for whatever test I want.
It seems the flags are not used in that situation.

I've tried ceedling test:path[dir] and that one takes the flags.

Any advice of what I could be doing wrong to not get compilation flags when running individual tests?

@mvandervoord
Copy link
Member

Hi. Are you running 0.31 or one of the 0.32 release candidates? :)

@lafonso-gnrc
Copy link
Author

hello,

I am using a snapshot, ceedling-0.32.0-164e950.

@mvandervoord
Copy link
Member

If you run as ceedling --verbosity=debug clobber test:blah where blah is a filename you want to run, it's not using the specified flags when compiling blah.c?

@lafonso-gnrc
Copy link
Author

--verbosity=debug doesn't seem to work so I used verbosity[4]

It does not show the specified flags. Double checking with ```test:path[]``, I can seel all the flags. I can see this at the start

gcc.exe -std=c99 -Wall -Werror=return-type

@mvandervoord
Copy link
Member

Thanks... and sorry about the wrong verbosity flag. It just changed recently and I wasn't sure which you had.

This definitely looks to be a bug. I don't know if you have the bandwidth to help debug it, but if you do, can you try this:

In the Ceedling gem (depending on your OS, you might be able to find it using which ceedling), you want to open the file rules_tests.rake. Somewhere around line 30, you'll see this:


namespace TEST_SYM do
  TOOL_COLLECTION_TEST_RULES = {
    #:context        => TEST_SYM,    <---- yours doesn't start with # but try adding it and saving this file
    :test_compiler  => TOOLS_TEST_COMPILER,
    :test_assembler => TOOLS_TEST_ASSEMBLER,
    :test_linker    => TOOLS_TEST_LINKER,
    :test_fixture   => TOOLS_TEST_FIXTURE
  }

See if that makes any difference to your setup?

@lafonso-gnrc
Copy link
Author

I'm running it on windows because IAR and avoid switching between filesystems. gem which ceedling works for it.

This is what mine looks like initially

namespace TEST_SYM do
  TOOL_COLLECTION_TEST_RULES = {
    :test_compiler  => TOOLS_TEST_COMPILER,
    :test_assembler => TOOLS_TEST_ASSEMBLER,
    :test_linker    => TOOLS_TEST_LINKER,
    :test_fixture   => TOOLS_TEST_FIXTURE
  }

Changed to this and ran ceedling again. can-t really tell any difference in behavior or flags in verbosity.

namespace TEST_SYM do
  TOOL_COLLECTION_TEST_RULES = {
    :context        => TEST_SYM,
    :test_compiler  => TOOLS_TEST_COMPILER,
    :test_assembler => TOOLS_TEST_ASSEMBLER,
    :test_linker    => TOOLS_TEST_LINKER,
    :test_fixture   => TOOLS_TEST_FIXTURE
  }

@mvandervoord
Copy link
Member

Thanks. You can switch it back. I'm going to try to replicate your issue here and see if I can figure out what's going on. :)

@lafonso-gnrc
Copy link
Author

thank you, I appreciate it

@mvandervoord
Copy link
Member

Are you in a position to update to the latest release candidate? I don't see anywhere that we should have fixed this issue specifically, but I also am unable to reproduce it using the latest release candidate.

@lafonso-gnrc
Copy link
Author

I might get a chance to try this at some point, maybe only over the weekend

@lafonso-gnrc
Copy link
Author

I tried doing this on WSL to not break my windows build environment. It had already a ceedling version installed.

I've done sudo gem install --local <path> with release candidate [0.32.0-25f0aa4]. It doesn't seem able to identify the project as a ceedling project and I get these errors when doing ceedling help

🪲 ERROR: Plugin 'stdout_pretty_tests_report' not found in built-in or project Ruby load paths. Check load paths and plugin naming and path conventions.
🪲 ERROR: Plugin 'warnings_report' not found in built-in or project Ruby load paths. Check load paths and plugin naming and path conventions.

I got to try this in a fresh install and project at some point. In general it seems like I randomly get features disabled/broken depending on the release candidate I try, probably due to already have previously installed versions.

@mvandervoord
Copy link
Member

You'll want to check the release notes, particularly the file in the docs folder called BreakingChanges.md. The plugins you're referencing above have been replaced with new versions with a more consistent naming convention.

In this case, the plugins you want are the following:

:plugins:
  - report_build_warnings_log
  - report_tests_pretty_stdout

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants