Build configurations using libraries with identical names

[freeck]

No idea wether this is a question about Eclipse or about Sloeber....
I have created 2 build configurations for one application, one for the esp8266 and one for the esp32. Thus maintaining a single source code for 2 platforms.
Each platform use different libraries (like wire or spi) but having identical names, and located in the 2 different locations of the 2 packages. In case I switch to the other platform one would expect that the library points to the library belonging to the chosen platform. Unfortunately this does not happen for libraries having identical names.
Excluding the library and import the other library (having the same name) does not work. My workaround is to rename each library (having identical names) with a prefix of "ESP8266" or "ESP32". For example: rename the SPI-library to ESP8266spi and ESP32spi..... Perhaps I do something wrong or is it a known issue.
Thanks in advance for suggestions to handle this.

[jantje]

I have created 2 build configurations for one application, one for the esp8266 and one for the esp32. Thus maintaining a single source code for 2 platforms.

This is the best way to do this. Even though it has some caveats as discussed below.
But first the good news. IMHO As wire and SPI are both platform libraries in "ESP8266" and "ESP32" they should work fine. The Ethernet library and switching between a AVR and ESP board will require manual setup.

One thing to realize is that there is a huge difference between arduino IDE and Sloeber in regards to handling platform and library code. Arduino IDE simply doesn't allow access to this code. This way the libraries only need to be identified at build time.
In Sloeber the libraries are known at coding time. Therefore the libraries/platforms need to be identified at configuration changes (both switching and changing)

Switching configurations "the right way"

CDT allows multiple ways to switch the configuration but not all are supported as well with Sloeber (it improved a bit in the latest versions). The safest way is to go to project properties->arduino->set the active config-> select apply/close
You can also try to delete the libraries after a config switch or the menu Sloeber->reimport libraries after a config switch

Verifying the indexer settings

Sloeber relies on the indexer to provide lots of the Arduino functionality. This means "The indexer is wrong->Sloeber is even more wrong".
In a multiple configuration environment setting the indexer settings correctly is vital. Below are what I think works best.
I highlighted the most important once

Be patient and give Sloeber some time

When you changed the configuration a event is triggered that triggers a event that triggers a event that triggers a event that triggers a event that ....
So lots of things happen and it will take time for Sloeber to catch up.
Add to that the fact that indexing of ESP projects takes a long time; and that after the indexing Sloeber starts to do changes that will trigger the indexer (in your case).
In the right corner of the screen you can see what Sloeber is doing and you can double click to see the list of remaining actions.
In the event logger you should see messages about sloeber doing library changes.
As long as the transition is incomplete; both the indexer and the build will return unexpected results

Get rid of the .ino file

Sloeber supports .ino files to allow developers writing libraries so they can develop the samples in Sloeber. In projects that use multiple config's pointing to different platforms I strongly recommend to drop using .ino files.
.ino files are processed by sloeber based on indexer information to make the sloeber.cpp file. The change of the sloeber.cpp file triggers the indexer, triggers the creation of the sloeber.cpp file,triggers the indexer ....

If all above fails .. do it yourself

Sloeber builds all the code from the root. In essence there is no difference between the core folder the libraries folder and any other folder in your project. Except for: Sloeber maintains the core and libraries folders (and meta data like include paths) and you do the others.
Also note that there is nothing special about the names except for: these are the folder names Sloeber looks for.
So you can easily create a "ESP32Libraries" folder and have (some of) the ESP32 libraries in there. (and a ESP8266Libraries folder for the other)
Unfortunately this is not the end of the story (and this is why getting Sloeber to manage stuff is easier as it maintains the "meta data" for you).
You need to use the CDT functionality (right click the folder/file->resource configurations->)"exclude from build" to exclude the ESP32Libraries from the ESP8266 config and ESP8266Libraries from the ESP32 config.
You will also need to maintain the include paths in the project properties of both configurations or the libraries will not be found and sloeber will try to add the libraries to the libraries folder for you (unless you forbid Sloeber to do so -which I would advice at least during project setup-)

I hope this helps
Jantje

[freeck]

Hi Jantje, Thanks for your elaborate answer. Very instructive and helpfull for developers. I followed your instructions but unfortunately it did not solve my problem. I cannot find an "automatic way" to cope with libraries with the same name, switching between 2 platforms i.e. ESP32 and ESP8266, without manual intervention. You cannot exclude a library from the "build" and then include a library with the same name; it always replaces the other library, even when you exclude the other lib from the build.
So, until there is no better approach, I use my quick and dirty solution by renaming identical library-names with a prefix of ESP32 or ESP8266. In that case switching between platforms always works automatically.

[PerennialNovice]

Hi jantje,

thank you for these instructions on using different configurations.
Nevertheless I did not manage to gt it working.
I have an AVR project on which I would like to add STM32 as a platform.
The hint to manually delete and re-add libraries helped me a lot, at least now I can go back to AVR configuration and it builds.
But switching to STM32 does not work yet.
To me it looks like some of the core-libraries are not included during build.
The compiler complains about 'I2C_HandleTypeDef', 'I2C_TypeDef', 'i2c_t', ... beeing unknown types. These should be found in the µC.specific include files like system/Drivers/STM32L4xx_HAL_Driver/Inc/stm32l4xx_hal_i2c.h

So my guess is that something very crucial in the underlying mechanism is not gathering all the necessary files for STM32.

I created a new project with the exact same codebase and choose STM32 from the start as platform and that one builds perfectly well, so I am confident that a solution to switch configurations is possible.

[jantje]

I think your problem is related to the indexer providing errors and not to sloeber adding wrong libraries as OP was talking about.

[PerennialNovice]

Oh - sorry for misplacing my question/comment

Shall I open a new topic on this or can it be converted?

[jantje]

If you really are mastering the mess you know that everything is one big continuum and we humans decide where we put borders and how we name it. Libraries is such a mess. Not only is it a place to go and lend/read books,it is also a collection of code. Depending on the code flavour libraries may mean very different things. And here in sloeber (a gathering of stuff) libraries can mean loads of things. No wonder people get confused.
We try to cope this confusion by ignoring the problem or by adding prefixes to words: like arduino library or platform library or toolchain library. However the second gets us into boredom so fast we mostly opt for the confusing library. The same goes for arduino, toolchain, error, program ....
About errors:
CDT (on which sloeber is build) provide 2 types of errors. One is from the indexer and the others are from the build. If your project builds but you CDT reports errors you are looking at indexer errors. However annoying these errors are (like a fire alarm you can't turn off, when there is no fire) ; stuff is working.
That is why phrases like "but the project builds" are magically helping to lead us to the root identification.
When the project builds we know all needed arduino libraries have been attached to the project (there may be to many) and what is more we also know that if there are errors these errors come from the indexer.

But why is the indexer so easily confused? After all it only needs to parse the available code.
Nope. There is way more than parsing the available code. There is also the question "what is the available code?" and there is the question "what are the defines?"
To answer these questions CDT questions the toolchain and that toolchain changes with the arduino product which is something CDT did not foresee nor knows about.
So when you change configuration Sloeber has to tell CDT that the toolchain changed, but also it's include path and the source tree. One would think one masters the mess when Sloeber instigated the configuration change and when sloeber is done CDT kicks in. But one would be wrong. Because for Sloeber to finish it needs input from the indexer which is CDT.
Yes it is a mess and there is no mastering the mess, only hard work to pick up the remaining ends and fix them. Until somebody fixes some remaining end; which makes new ends pop up.

What I'm trying to say is that switching configurations with different toolchains in principle works but there are loose ends. These loose ends are more clearly visible when ESP toolchain is used as ESP takes a long time to index.

If you really need to switch often between 2 configs for the same source code I would consider using 2 projects linking to the same source code and having different toolchains.

[freeck]

If you really need to switch often between 2 configs for the same source code I would consider using 2 projects linking to the same source code and having different toolchains.

Thanks for your latest suggestion, I will give this a try.
Btw, I am very satisfied with Sloeber!

[PerennialNovice]

I do very much agree with freeck that Sloeber is a very fine gathering of stuff :)

And sorry for the unprecise formulation of my problem. It is not an indexer problem, it's the compiler that runs into build error.
I too will go the 2 projects way since after all I don't see that much advantage (at first thought even not one) in using a single project with 2 configurations.

Thank you for your help @jantje !

[jantje]

after all I don't see that much advantage (at first thought even not one) in using a single project with 2 configurations.

One advantage is that multiple configs doesn't clutter your projects view. For most serious projects I have a release/unit_test/local_debug configs. Having these in projects that would triple my number of projects (which is already way to big :-( )
Another advantages is that a configuration is also less cpu -at startup- and memory costly because only one config is loaded into memory. However this means that at config swap you pay a cpu cost. You can avoid this cost by closing projects which is a manual action.
A last advantage I can think of is that it is easier to identify human errors that cause differences between the 2 configs then 2 projects.

So in my view there are 2 parameters that decide on project versus config.

1. how heavy is the config change
2. how often do you do the config change.

The heavier the toolchain and the bigger the number of libraries used the heavier is the config change. If you only swap between 8 bit AVR toolchains/boards you can safely use configs (even when using a relatively big amount of libraries).

IMHO If I would have to use the heavier toolchains/boards like ESP and swap on a daily basis; I'd probably go to multiple projects.

Note that if #1432 ever gets implemented this may change because the library swap would no longer be dependent on the indexer outcome at the time of the config swap.

[jantje]

if you do the 2 projects approach try linking to folders as much as possible as it will be easier to maintain.
If the project containing the linked folder does not show new files (yet) press the F5 button (refresh)