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

Document how to use custom mbed-os version in platformio #214

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

douardda
Copy link

@douardda douardda commented Oct 3, 2021

No description provided.

@CLAassistant
Copy link

CLAassistant commented Oct 3, 2021

CLA assistant check
All committers have signed the CLA.

Custom version of Mbed
^^^^^^^^^^^^^^^^^^^^^^

PlatformIO comes with only a few versions of Mbed supported out of the box. If you want
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd change this wording to something like "PlatformIO only has certain versions of mbed-os in the official package package registry, as queryable through the API", just to give people a pointer as to where to find natively supported versions.

@maxgerhardt
Copy link
Contributor

The general problem with telling people how to use custom versions is that they then think

  1. Using custom mbed-os versions like that is officially supported by PlatformIO staff (there's a "no beta software supported" policy, and one can think of "beta" as "outside of official PlatformIO repositories" here)
  2. That it will always work without problems, when e.g. for 6.15.0 it does not because as outlined of a Python dependency missing out-of-the box. People would then have to have a slightly deeper PlatformIO knowledge to understand where the Python / pip installation that PlatformIO is using is and fixup that. And if the builder script starts to fail for newer mbed-os versions because they changed their build API, it's going to be even more complicated for non-staff to fix it. The documentation does not mention all these caveats.

This is definitely useful information for many people, but having it in official docs would give a false sense of "this always works, just do that".

}
EOF

Then one ca use the following `platformio.ini` file:
Copy link
Contributor

Choose a reason for hiding this comment

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

slight typo in ca -> can here

platform = ststm32
framework = mbed
platform_packages =
framework-mbed @ file://framework-mbed
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. configuration is missing board = ... line to make it complete, does not mention to add it
  2. Maybe general link to https://docs.platformio.org/en/latest/projectconf/section_env_platform.html#platform-packages would be good

@douardda
Copy link
Author

douardda commented Oct 7, 2021

Thanks a lot @maxgerhardt I'll try to address your comments ASAP.

@douardda
Copy link
Author

douardda commented Oct 9, 2021

The general problem with telling people how to use custom versions is that they then think

1. Using custom mbed-os versions like that is officially supported by PlatformIO staff (there's a "no beta software supported" policy, and one can think of "beta" as "outside of official PlatformIO repositories" here)

2. That it will always work without problems, when e.g. for 6.15.0 it does not because [as outlined](https://community.platformio.org/t/support-for-mbed-os-6-stable-and-mature-apis-cloud-services-support-enhancements-to-the-bare-metal-profile/15079/10?u=maxgerhardt) of a Python dependency missing out-of-the box. People would then have to have a slightly deeper PlatformIO knowledge to understand where the Python / pip installation that PlatformIO is using is and fixup that. And if the builder script starts to fail for newer mbed-os versions because they changed their build API, it's going to be even more complicated for non-staff to fix it. The documentation does not mention all these caveats.

This is definitely useful information for many people, but having it in official docs would give a false sense of "this always works, just do that".

I agree and propose to include a big disclamer in this section.

@douardda
Copy link
Author

douardda commented Oct 9, 2021

I've updated a bit the PR, hopefully addressing all your comments.

Thanks again.

@mmontag
Copy link
Contributor

mmontag commented Jan 24, 2022

Bump...merge this?

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

Successfully merging this pull request may close these issues.

None yet

4 participants