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

Environment variables at flags and define fields #879

Closed
claudiiolima opened this issue Apr 16, 2024 · 5 comments
Closed

Environment variables at flags and define fields #879

claudiiolima opened this issue Apr 16, 2024 · 5 comments

Comments

@claudiiolima
Copy link

When use environment, #{ENV[SOMETHING]}, on flags or defines fileds, the variables aren't interpreted.

@claudiiolima
Copy link
Author

claudiiolima commented Apr 19, 2024

Fo example, on defines field I would like to use something like:

:defines:
  :release:
    :compile:
      - BOARD_REVISION=#{ENV['REVISION']}

NOTE: I tried to use double quotes too.

  • "BOARD_REVISION=#{ENV['REVISION']}"
  • BOARD_REVISION="#{ENV['REVISION']}"
  • \"BOARD_REVISION=#{ENV['REVISION']}\"
  • BOARD_REVISION=\"#{ENV['REVISION']}\"

@deltalejo
Copy link

deltalejo commented Apr 20, 2024

I came across the same limitation some time ago. There is also an old issue about the same problem. A possible workaround would be to add the -D option to the compiler's arguments inside :tools section. e.g:

:tools:
  :test_compiler:
    :name: awesome_compiler
    :executable: awesomecc
    :arguments:
      # some arguments
      - -DBOARD_REVISION=#{ENV['REVISION']}
      # more arguments

But then you probably need to add the same argument to other tools, and now it gets quite cumbersome. So it will be nice to have the tool element runtime substitution also working for other sections for the project config file, as you mention: :flags and :defines.

@claudiiolima
Copy link
Author

Thank @deltalejo for your comments.

I'm using exactly this workaround, but it's becoming somewhat unproductive.

I will try to solve this issue and make a pull request

@claudiiolima
Copy link
Author

@deltalejo maybe you can try the pull request above if you still need this feature.

This is my first contribution, so I hope everything goes well.

@mkarlesky
Copy link
Member

Thank you for highlighting this and tying together PRs and existing issues. This is a good feature. I will be adding it to the latest pre-release version of Ceedling soon.

I am going to reject the PR but for a simple reason. Like path standardization and related tasks, this should all be collocated in the startup steps that process configuration before its used. The string replacement in tool handling is some of the very oldest code in Ceedling. It's not a pattern that should be copied elsewhere. We'll centralize this during configuration processing. This will have the added benefit of producing configuration modifications you can see and verify by running the new dumpconfig command line.

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

3 participants