Developing a library - libdeps cache gets in the way

Libraries
1

I’m trying to modify a library that is used by a project.

To do that I’ve placed the library sources in a local folder, and pointed lib_deps to this folder using full local path “c:\dev\my_library”
The code builds correctly the first time build is run, but all subsequent modifications of the sources are ignored.
Also, code navigation features of VSCode like “go to declaration” go to the cached copy in .pio\libdeps and not to the original sources I’m editing.

Any ideas what I am doing wrong ?

(platform = espressif32, framework = arduino)

2

Either use lib_extra_dirs or use lib_deps but with the symlink:// directive (used in a different command e.g. here).

3

Thanks for the quick answer.
Tried prefixing the path with symlink:// and I’m getting this error:
VCSBaseException: VCS: Unknown repository type symlink://C:\Dev\my_library

The linked documentation of lib-extra-dirs doesn’t mention that it disables caching - what’s the rationale for it?

4

Can you open a CLI and use pio upgrade --dev and retry with the symlink? The change might be quite new.

2 Likes
5

Now that both solutions work :slight_smile: - why would specifying the full local path go through cache, and using lib_extra_dirs for lookup bypass the cache ?

6

Good questions, since I’m not a PlatformIO developer / designer I can’t answer that. For file:// libraries maybe a symlink by default would be better… But on the other hand, if the original folder is deleted, compilation breaks. You can propose changes to that caching system via Issues · platformio/platformio-core · GitHub.

7

That’s the whole point of symlink:, I think:
https://docs.platformio.org/en/latest/core/userguide/pkg/cmd_install.html?highlight=symlink#local-folder

The file: version fetches a local copy and never looks back, just as it does for other URLs referring to remote libraries. The symlink: model avoids copying and continues to track changes, so that the project will rebuild if the library changes. It’s super convenient for a range of usage scenarios, IMO.

See also Migrating from 5.x to 6.0 — PlatformIO latest documentation.