Skip to content

Tools: Restrict toolchains reported by mbed compile -S to official ones #8249

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

Merged
merged 3 commits into from
Oct 19, 2018

Conversation

theotherjimmy
Copy link
Contributor

Description

The mbed compile -S command is suposed to indicate what targets
support what toolchains. The command was printing out things that
don't make sense, like GCC_CR and things that make sense, but are
not offiially supported yet, like ARMC6. This PR fixes all of that.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

Copy link
Contributor

@0xc0170 0xc0170 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this available anywhere as a list (similar to other like allowed_features, etc): SUPPORTED_TOOLCHAINS ?I assume we check the validity for supported toolchains somwhere

unique_supported_toolchains.append(toolchain)

return unique_supported_toolchains
return ["ARM", "uARM", "GCC_ARM", "IAR"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid creating a disconnect between the toolchain implementation, can we reference the keys present here instead:

TOOLCHAIN_CLASSES = {

I realize ARM6 is in that list though. So that would mean just removing it from the list here by name, or adding a "supported" variable (or something similar) to the toolchain class and then filter on that here.

@bridadan
Copy link
Contributor

Side note, there are quite a few targets in targets.json that still list GCC_CR as a supported toolchain. Is it safe to go ahead and remove that compiler from those targets? Looking at the our supported toolchain code it doesn't look like we support that compiler anymore anyway.

@cmonr
Copy link
Contributor

cmonr commented Sep 28, 2018

Side note, there are quite a few targets in targets.json that still list GCC_CR as a supported toolchain. Is it safe to go ahead and remove that compiler from those targets? Looking at the our supported toolchain code it doesn't look like we support that compiler anymore anyway.

I would think it should be fine. Not even sure what GCC_CR is. @ARMmbed/mbed-os-test Thoughts?

@bridadan
Copy link
Contributor

bridadan commented Oct 1, 2018

GCC_CR referred to a variant of GCC called "Code Red" that used to be used (I think with some NXP products, can't remember). Anyway, I don't think you can get the compiler anymore so I think it should be ok to remove. Probably better to move this to a separate issue.

@0xc0170
Copy link
Contributor

0xc0170 commented Oct 2, 2018

I would think it should be fine. Not even sure what GCC_CR is. @ARMmbed/mbed-os-test Thoughts?

Not valid anymore, can be removed.

@bridadan bridadan mentioned this pull request Oct 2, 2018
@theotherjimmy
Copy link
Contributor Author

@bridadan review please.

Copy link
Contributor

@bridadan bridadan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OFFICILLY_SUPPORTED is misspelled :)

Also, can we just say supported or released? We don't currently have a distinction between official/unofficial right?

@@ -48,6 +48,8 @@
CPU_COEF = 1

class mbedToolchain:
OFFICILLY_SUPPORTED = False
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the mispelling

### Description

The `mbed compile -S` command is suposed to indicate what targets
support what toolchains. The command was printing out things that
don't make sense, like `GCC_CR` and things that make sense, but are
not offiially supported yet, like `ARMC6`. This PR fixes all of that.

### Pull request type

    [x] Fix
    [ ] Refactor
    [ ] Target update
    [ ] Functionality change
    [ ] Breaking change
@cmonr cmonr force-pushed the official-tc-support branch from 5d2df3d to ec72ce7 Compare October 18, 2018 16:12
@cmonr
Copy link
Contributor

cmonr commented Oct 18, 2018

@bridadan Typo corrected.

@theotherjimmy Thoughts on doing s/OFFICIALLY_SUPPORTED/SUPPORTED/g?

@cmonr cmonr dismissed bridadan’s stale review October 18, 2018 16:14

Typo updated. Re-review requested.

@cmonr
Copy link
Contributor

cmonr commented Oct 18, 2018

@bridadan I think the idea is that in the past, there's been confusion about compilers being enabled vs supported in the tools. The thought goes, being a bit more verbose about this helps makes this a bit clearer, and can help contextualize questions if/when they come up.

@bridadan
Copy link
Contributor

I think the idea is that in the past, there's been confusion about compilers being enabled vs supported in the tools.

Yeah fair point, though I would think "enabled" would mean it's in the tools (an implementation exists) and "supported" would mean the flag is set. But if this helps clarify it more then I don't feel that strongly about it 😄

@cmonr
Copy link
Contributor

cmonr commented Oct 19, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Oct 19, 2018

Build : SUCCESS

Build number : 3409
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8249/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented Oct 19, 2018

@mbed-ci
Copy link

mbed-ci commented Oct 19, 2018

@cmonr cmonr merged commit c40d860 into ARMmbed:master Oct 19, 2018
@cmonr cmonr removed the needs: CI label Oct 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants