this seems to be quite common but I have found myself in conflict with the LDF, and I am really lost as to why it’s unable to find my library in the lib/ folder unless i specify lib-extra-dirs as ./lib which
A: shouldn’t be necessary because the lib folder should be the place the LDF looks first for libraries
B: still fails to build in the end because even though it finds the library after that, it then is unable to follow the references in the library to things in my inc/ folder.
Here is case A with as much information as I can summarize in a single screenshot:
I’m a little lost here, because as far as I can tell there should be no issue with my library.json so it should be able to find the library with the structure I created it in, it matches the structure in the readme file.
The build flag paths in your library.json are wrong. The src folder of the library is automatically added to the include path, so you do not needed -I FS-CAN/src. In any case, the path would be wrong anyways since the path is expected to be relative to the root of the library (which is already lib/FS-CAN).
I would just recommend you to remove the whole build section of the library.json and let the defaults handle it.
That doesn’t quite solve the issue, as without lib_extra_dirs = ./lib the LDF doesn’t even look for my library at all and doesn’t get to the point where it would have handled the build commands. I removed that section anyways, but for more insight, here’s the build output when I don’t have the lib_extra_dirs = ./lib:
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ deep+, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
and here it is when I put it back:
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ deep+, Compatibility ~ soft
Found 1 compatible libraries
Scanning dependencies...
Dependency Graph
|-- FS-CAN @ 0.0.1
Building in release mode
The first thing I’m trying to understand is why I need to add the lib path manually to the lib_extra_dirs variable considering that should be the default location for libraries.
Case B i kinda have a rough idea about but I’m not quite sure how to be entirely honest
Of yeah because somehow lib_dir = Core/Startup is set, which overrides the default lib_dir = lib setting, so your… Core/Startup folder has become the folder which PlatformIO searches for libraries. So yes you workaround that with lib_extra_dirs.
This entire project layout is beyond weird. src_dir = ./ as in “every source file in this project folder shall be compiler” and thus the library folder being inside the source folder now although they should be separate surely makes for some weird things.
To get to the point: Do you really need this nonstandard project layout? Usually peopel generate a STM32CubeMX base project once with all the peripheral setups they need, then they take those source files into PlatformIO in the standard project folder structure. I guarantee you this will cut out these weird problems.
Ok yeah I guess that makes sense. I was reading through the script that orchestrates this entire mess and it seems it treats the entire project as Src and Inc. Although if you recall from my previous thread it seems to conveniently ignore the startup folder since I had to move my linker script to the src directory. Anyways I’m getting side tracked.
I spent many many hours trying to generate the project in cubeMx then move the source files and drivers into platformio but the issue is for whatever reason, no matter how hard I followed the tutorial in this forum that explained how to do it, it never quite worked, but this …mess works for now at least. I think part of that had to do with the fact that specific chip (STM32H723) is not officially supported by the libraries that platformio has in it’s index, which meant I basically had to copy over all the HAL libraries over manually anyways which never quite worked for me when I just dropped the HAL Driver folder and the CMSIS folder into lib/ and it didn’t help that I also needed FreeRTOS as well.
Anyways I know this project setup has been a mess and is probably pushing the boundaries of what platformio is supposed to do, I really appreciate all your help with this whole thing.
The library issue I’m coming across I think would have happened even following the standard format. I think once I sort out this library dependency ordeal I should be good to go. Basically my library uses some of the Typedefs from the STM32_HAL, so when it tries to compile the library and gets to the #include for the hal.h file, it doesn’t find it in the library itself, and thus cannot compile. Perhaps this isn’t possible at all but I’m sure there are plenty of libraries that depend on other libraries, and in the examples, in the library.json file, they call out those dependencies in the "dependencies" section of the library.json, however those tend to point to URLs or names of packages in the pio package index. But my dependency is in the project itself, so I tried:
Update: the file it can’t find is the stm32h7xx_hal_conf.h not stm32h7xx_hal.h. The first being in my Core/Inc folder. It wasn’t having a problem with my drivers folder.
Update 2: this is probably super improper but the “fix” was: lib_extra_dirs = ./Core/, ./Drivers/STM32H7xx_HAL_Driver, ./lib
I don’t know why it needs both the core folder and hal folder again but I’ll take my wins where I can
Another update in case another unfortunate soul comes across this thread in the future. I found the better solution here is to actually append the path of the library to include_dirs in a build script (extra_scripts in platformio.ini), I’m not sure why, but it doesn’t work if you just add `-I// as a build flag in platformio.ini, but works if you do it in the prebuild script. Not sure why, but in case any future people come looking, thought I’d put it here.
