I’m working on my main code and I’ve need to modify someone else’s libraries.
So I forked a copy and I include that in my platformio.ini.
lib_deps =
# Using a library name
Library1
Library2
https://github.com/me/mylibIwanttomod.git#tag_I_want
So I make the changes but under the source control tab I only see pending changes to my main program. Nothing about the library in .piolibdeps which I modified.
As you can tell I’m kinda newbie at this.
Am I going about this the wrong way?
Do I need to check it out via command line to a different folder and then specify that include folder? And then am I going to be forced to used the command line to make my commits?
I really like the visual notifications of changes vs stock…
Does VSCode show you the modifications to the library when you have opened one of its source files? What does git branch -a show in the library folders?
Btw because of the .gitignore containing .piolibdeps, git will not push the contents of that library into the repository of your main firmware.
No… VSCode doesn’t show the mods. Only my main code shows the mods.
git branch shows no branch
I’m guessing that it just downloads the code vs doing a checkout? I see the gitignore.
So do I have to manually checkout the library in a separate folder?
I can’t be the first one to do library development as well as main program development at the same time!
I deleted the .pioenvs folder. Recompile. Nothing at all about a git clone.
Nothing at all about git.
I do see a .git file in the .piolibdeps/mylibrary folder. And I can see differences when I do a tortise git diff on the two library files I changed. So I guess I can manually commit the changes. But it would be nice to see them in the editor. I wonder if I comment out the piolibdeps in the git ignore file… hmm…
I think the problem you are facing here is because of nesting… you have your main code, which is source controlled in one repo, and you have your library (cloned into to .piolibdeps), source controlled in another repo. VSCode doesn’t seem to be able to hand the nesting… if you add the library folder to the workspace, try to open the git repo manually (View -> Command Palette -> Git open repository),etc it doesn’t seem to do anything. You’ll probably have to use the command line to manage the nested repo, or use a external GUI tool like Github desktop or TortoiseGit.
Ok… I guess I’m stuck using the external gui stuff. It would have been nice to have PIO or VSCode handle it. But if It’s not possible.
I can’t be the only one who’s developing a library and a main program at the same time.
Sure. I can try to set something up.
But… Maybe I’m just doing something wrong.
Say I have my main code in Repo A and I have my own library in Repo B.
How do I use my library in Repo B in my main code project in Repo A and still make and see changes to my library (repo B) while working in the main project?
I’m sure I’m not the only one that develops library code while working on main code…
What’s the best way to do this? If I import the library in plaformio.ini into .piolibdeps then it doesn’t track repo B.
Since what it sounds like you really want is for the library to be tracked the VSCode source control view… how about having that library in another folder, and adding that to the VSCode workspace? In other words, completely ignore the version in .piolibdeps… let platformio manage that copy.
i.e say for my tracerWifi project code, say I needed to make changes to the elaspedMillis library (which I’m a maintainer of) … so I have it set as a git style lib_deps dependency for my tracerWifi project, and git clone the elapsedMillis library somewhere else onto my computer (e.g. /home/pfeerick/repos/libraries/elapsedMillis) and then added that folder to the VSCode workspace… (File -> Add Folder to Workspace). You get source control views for your main code and for your library…
The only tricky bit I see happening is that in your main code, you might need an extra_script to ensure it always does a git pull if needed to ensure it has the latest commit of the library…
Actually, on second thoughts, I think your original idea was spot on… clone it out to a separate folder (e.g. /home/pfeerick/repos/libraries/elapsedMillis), add the library folder to the workspace, and then tell platformio about that libraries folder in your platformio.ini like lib_extra_dirs = /home/pfeerick/repos/libraries/ … that seems like it should work… you get both the locally editable library, which is used by your main code, and since you’ve added it separately to the workspace, it shows up in source control.
You should delete the copy of the library in .piolibdeps as you don’t want your main code using that version at all, and you don’t want it mentioned in the lib_deps of your main codes platformio.ini, else platformio will try to download it again, instead of using the copy in the lib_extra_dirs path.
PS: I’m only just starting to look at it myself, but git submodules might be the way to do it ‘properly’… I just don’t know yet how the VSCode source control viewer handles it… or if I’ll just use GitKraken to manage them…
Addendum: It looks like the answer is ‘just fine’… Using a non-platformio-managed library, VSCode’s source control system correctly identified the submodule as a submodule, and added a handler for it… So with a bit of tweaking, that looks to be the better way to track nested repositories with VSCode also… as you’re basically acknowledging in the repo itself that they’re linked.
I am also trying to develop an application and libraries at the same time. On top of that, the application runs on different hardware.
The inherent problem with pio and vscode, any libraries in the lib_deps section are downloaded to the .pio directory which is essentially a temporary working directory. And further to that, if there are multiple env specified, the library is cloned once for each env. I have also been unable to get the vscode source control to monitor those libraries.
The best solution I have found so far is to not use lib_deps but lib_extra_dirs as suggested earlier. In my case, I have three folders in a lib folder, shared, arduino and boards, in which the required libraries are installed. The lib folder can now be added to the workspace in vscode and source control will pick up any changes.
In platformio.ini I can control which libraries each env have access to. They all have …/lib/shared and …/lib/arduino in the lib_extra_dirs and differ with the boards which could be …/boards/esp32devkit or …/boards/promini.
This is all working fine for me except for one thing. Although everything compiles without warnings or errors, the ide is flagging errors that include files can’t be found. Files within the pio project, such as main.cpp, are fine but files in the lib folder get flagged with an error by the ide “can’t find <Arduino.h>” for example. The main.cpp file does not have the error but files in the libraries do. Although everything compiles ok it’s a bit annoying having lots of red warnings about missing include files.
Does anyone have any suggestions as to a fix to the #include problem?
First of all you should try and refresh the IntelliSense with Ctrl+Shift+P → Rebuild IntellISense.
The configuration for the IntelliSense happens via the .vscode/c_cpp_properties.json file of a VSCode workspace folder. I’m not sure that if you add your library via to the workspace as a separate folder that it is affected by the project’s c_cpp_properties.json file – without that information, VSCode’s IntelliSense can’t work properly. You can mabe try and copy the project’s .vscode folder into the library folders to get better IntelliSense in the library code.
Otherwise I can suggest putting the library in lib/ and developing it there and copying it outside after it’s developed. You can also symlink say lib/mylib to some outside folder where you want to keep the library if you somehow develop the library in multiple projects at once.
Thanks for the prompt and comprehensive reply. I did try rebuilding intellisense but that did not fix the problem.
As you suggested, I copied the .vscode folder from the pio project into the lib directory. Bingo! It works. Thanks.
To handle the changing env for different boards, I changed the directory to a symlink between the lib and the project .vscode directory. Now when the build environment changes, so does the include paths, so ctl-click on Arduino.h brings up the right one!
The only thing I need to be careful of now is when changing projects is to update the symlink to the new project.
Just as a note, using the lib directory is something I tried but has a small problem. When the LDF scans the source code, libraries are included in the build even when the header is excluded by a preprocessor conditional. This makes it impossible to control library compilation passing -D flags to the compiler. Using the lib_extra_dirs achieves the result I need.
