copy libraries instead of linking

[PerennialNovice]

Hi,

I'd like to have the libraries used in a project in git as well.
Is it possible to have the library files actually copied into the PROJECT_LOC\libraries folder?
I tried manually copying the libs to a folder inside PROJECT_LOC and linking to them instead, but as soon as a new lib is added, all the path go back to standard.
Having relative path here would also be nice, or at least something like WORKSPACE_LOC or PARENT-n-PROJECT_LOC.

How can I achieve this?

[jantje]

yes it is possible but what do you want? There are many ways to understand the request "I'd like to have the libraries used in a project in git as well."
first of all : "PROJECT_LOC\libraries" is controlled by Sloeber. If you start messing around there you will cause issues.

The 2 ways I advice to use libraries is

1. put your libraries in a version control repository and point to this repository using private libraries.
   If you import this repository into your workspace you can monitor the changes in Sloeber
2. create a myLibraries folder and copy/maintain your code here.
   You can also combine the 2 to keep everything in the same version control repository.

[PerennialNovice]

Hi jantje,

Thanks for your answer.
What I try to achieve, is have most files that belong to a project (or to several similar projects) "bundled" together in one repository.
It is roughly a "monorepo" approach.
What I thought was the main issue here, is that sloeber keeps looking for #includes and tries to find the corresponding files in the Arduino-IDE library folder (%userprofile%\Documents\Arduino\libraries on Windows) even if matching files are present in PROJECT_LOC\MyLibraries subfolder.
But even after moving them to a subfolder there, sloeber just kept adding links to ECLIPSE_HOME\arduinoPlugin\libraries\ where the libraries reappear magically after a manual delete...
Which sure is a nice feature but incompatible with my ideas on how to achieve my goal ;-)
Could you please further elaborate what is happening here in detail? Is sloeber actually downloading the libraries (don't think so, they appear "instantly" which I assume is not what a download with my slow internet connection would allow) or where do they come from?

[jantje]

Sloeber uses the CDT indexer to search for "unresolved includes" (some more background info on includes and unresolved include https://www.youtube.com/watch?v=5Yi5xeeqlsk )
When the CDT indexer finds unresolved includes sloeber checks whether you want Sloeber to try to resolve these. If you disable this functionality Sloeber does nothing.

If you enabled the functionality sloeber searches the installed libraries for matches. (This process can go wrong resulting in unwanted libraries including even more libraries)
Sloeber searches first the libraries provided by the platform containing the board, then the libraries provided by the private hardware and then the libraries installed by the library manager (based on the provided library json's).

The private library locations

The installed libraries

The provided library json files

If no matching library is found Sloeber checks the option.

If this option is not set sloeber stops searching. If the option is set sloeber checks the provided library json's for candidates and installs the library if a match is found.

If Sloeber added a library to the project the indexer will be triggered to scan the code. When the CDT index scan is done; Sloeber will ask the indexer for unresolved inclusions which may lead to new libraries added to the project.
In other words, the process is recursive.

[PerennialNovice]

Thank you very much for providing some insight on this subject.

Temporarily disabling the sloeber autodetect feature, importing my own libraries and re-enabling it did the trick.
Has to be done only once.
I think the workflow of first importing a library folder, and only after this adding the #include statement will be the easiest way to go.

... and thank you for creating and maintaining sloeber :)