-
Notifications
You must be signed in to change notification settings - Fork 183
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
Add C++ language standard menu item #205
Closed
Closed
Changes from 4 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
92a1803
Expose the language standard via the gui
DrItanium 51c149d
1284 clock settings
DrItanium aa59ea2
Language standard mode for 644, 324, and 164 as well
DrItanium 111269a
Remove the extra frequency groups
DrItanium 71d631f
Bind language standard to a separate variable
DrItanium 894fbd4
Default to gnu++17
DrItanium 0cc17fc
Merge branch 'master' into master_sync
DrItanium 0587c2a
import C++14 additional delete operators
DrItanium bf7e733
Whoops it is size_t not std::size_t...
DrItanium eaf051d
It's size_t not std::size_t...
DrItanium File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
compiler.cpp.extra_flags
property is already in use by the LTO board option:MightyCore/avr/boards.txt
Line 114 in 640d21a
Although it is possible to do this by using dedicated properties in each of the options and then defining
compiler.cpp.extra_flags
by referencing each of the dedicated properties (e.g.,compiler.cpp.extra_flags={lto_flags} {std_flag}
), the platform really shouldn't be using thecompiler.cpp.extra_flags
property at all, since it is intended to be left for the use of the platform user in order to allow them to customize the compilation command. If the platform authors uses these properties then when the user tries to use them their definition overrides the platform's definition of the property. The platform author has the power to use any arbitrary property name they like so they have no need to monopolize the user's properties.Some related discussion on that subject here: arduino/arduino-cli#846
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to know. I do not use LTO so I did not see the conflict / overwrite. I incorrectly assumed that
compiler.cpp.extra_flags
was unique to each menu item and was concatenated magically. After typing that previous sentence out, I realize how absurd that assumption was.Would updating the
platform.txt
to have acompiler.cpp.languageStandard
variable make more sense? While specific to the current problem, it would never run afoul of other places in the build process.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's a good approach. The alternative would be to use a single property for all the board level extra flags for each compilation recipe. For example:
boards.txt
platform.txt
But there's no functional different between the two approaches. It's purely a style choice, which would be for MCUdude to make. I'm only an interested 3rd party in this project.
Note that there is no magic to these particular property names. I just made something up at random for the sake of the example. They could just as well be named
foobar
. It can be a bit confusing because some property names have special treatment by the build system, but the platform author is also welcome to use arbitrary properties of any name they like as long as they don't collide with the build properties that have special treatment.I don't think so. The platform system is pretty complex and the fact that it uses this custom "properties" data format makes it even more difficult to understand. Fortunately, the documentation has improved a bit since the time I learned it mostly through reverse engineering the existing platforms and a ton of trial and error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose
compiler.cpp.languageStandard
overcompiler.cpp.board_extra_flags.std
because I have to deal with many compilers at work which do not use-std=
to specify the C++ language mode (--c++11, --eecpp, etc). Call it descriptive paranoia.Regardless of the style chosen by MCUDude, I really want the ability to change the C++ language standard without having to manually modify platform.txt.
Thank you for letting me know that I was clobbering options :).