How to be more specific when redirecting package locations?

,
1

With the eye on integrating PlatformIO into Embeetle IDE, we need to have more control over the project structure of a PlatformIO project. More in particular, all libraries and framework code needs to be inside the project folder, such that the whole project is self-contained.

@maxgerhardt helped substantially to achieve this (see PlatformIO integration into Embeetle IDE). He gave the following example of a platformio.ini file that redirects all packages and libraries into the project folder:

[platformio]
; redirect *all* packages, so e.g. framework-arduino-avr. 
; this would however also redirect compiler packages, like toolchain-atmelavr, which 
; you might want to .gitignore.. (they're OS  & arch specific anyways)
packages_dir = $PROJECT_DIR/packages
; redirect the standard `.pio\lideps` directory if needed for better visibility
libdeps_dir = $PROJECT_DIR/libdeps
; redirect global libraries which normall go into <home dir>/.platformio/libs
globallib_dir = $PROJECT_DIR/global_libs

[env:uno]
platform = atmelavr
board = uno
framework = arduino
lib_deps =
   bblanchon/ArduinoJson @ ^6.18.0

Unfortunately, this also redirects the compiler toolchain and flash tools (eg. avrdude) into the project folder.

QUESTION:
Can one have more fine-grained control over which packages get redirected? This way, we could redirect only the framework and library packages into the project folder, making an exception for compiler toolchains and flash tools.

2

This is impossible. What is the reason to install gigabytes of toolchains per each project?

3

Hi @ivankravets ,
The idea is to redirect the framework and library packages into the project folder:

📂 my_project
├ 📁 include
├ 📁 lib
├ 📁 src
├ 📂 packages
│ └ 📁 framework-stm32cubel4
└ 📄 platformio.ini

but redirect the tools into some external folder (or just let them end up in ~/.platformio/ as it happens now):

📂 ~/.platformio
├ 📂 packages
│ ├ 📁 toolchain-gccarmnoneeabi
│ ├ 📁 tool-openocd
│

It’s certainly not the intention to store the tools in the project directory. My apologies for this confusion.

4

I think it is a bad practice to allow developers to modify the original SDK/HAL/Framework source code. This the reason why we hide all packages from the end-user side. If some advanced developers need changes in the original software, there is advanced scripting Redirecting...