I’m still in the process to making myself familiar (learning) PlatformIO and I’m wondering; are in PlatformIO settings that applying
a: PlatformIO wide,
b: Workbench wide, or
c: Project wide?
Where can I read more about it?
Is there somewhere a tutorial or Wiki specifically to this topic?
If a further clarification is needed, please let me know.
Thanks for any suggestion.
PlatformIO also respects certain environment variables as an override or default value for some of the values you would usually set in the platformio.ini. These settings are documented in
PlatformIO does not have the concept of a workbench (a collection of multiple projects). It’s always per-project. A single project can have multiple environments though, e.g., compiling the same project code with different settings or for a different board. In that case, the [env] section in the platformio.ini applies to all other environments in the file. That is also documented in the links above.
Thanks for your reply. It helps a lot.
Still some questions remaining.
To avoid the multiple definition (and storage) of the same library in each platformio.ini file and therefore directories, could I install each library, let’s say in a sub-directory of ~/.platformio (e.g. ~/.platformio/libs/…) and include the path to this directory with recursively lookup in the “include path” of PlatformIO?
This way I could keep ‘generic’ libraries on a central location and if I should have a case were I need a specific library for a project, I still could have it defined in the project related platformio.ini file.
Or would that create some ambiguities and perhaps confuse PlatformIO which lib to use?
The practice of relying on previously installed global libraries is exactly not recommended, because then the platformio.ini does not “stand-alone” describe everything needed for the compilation of the project. That defeats one of the strongest points of PlatformIO: To have a config file that declares all dependencies (with their correct versions and authors) needed to compile the project. It downgrades its capabilities back to the Arduino IDE, which also relies on that.
You should take the best practices for library dependency management from the documentation.
I hear what you’re saying and can see some benefits of it.
However, doesn’t this concept contradicts the idea of libraries- one piece of code for multiple uses/projects?
But that might be just an ‘academical’ discussion in this context.
Thanks for reference to the documentation.
I will give it some reading time.
Fred