Skip to content

Sloeber does not update the hardware libraries when changing the boards.txtx (F.I. when switching between two versions of STM32 the hardware libs will point to the original STM32 libs ) #1679

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
PerennialNovice opened this issue Sep 3, 2024 · 5 comments
Labels
status: known limitation This is soimething we can live with

Comments

@PerennialNovice
Copy link

Since I ran into problems after upgrading from STM32core 2.7.1 to STM32core 2.8.1, I installed 2.7.1 again side by side with 2.8.1

image

When I switch to 2.7.1 in sloeber project properties, I get some "xyz undeclared" errors

image

and scrolling through the console output I see that several files are taken from 2.8.1 STM32core

image

I suspect this is the cause for the "undeclared" errors?

removing the 2.8.1 folder from the disk did not solve it.

I then noticed that several libraries where still pointing to the 2.8.1 version, but reattaching them via the "reattach all libraries" command did not work out. It attached libraries vor AVR arduino boards. I have configurations for both AVR and STM32 for this project.

I then manually removed and reattached the libraries via the "add a library" button, which did not help either. I checked all libraries and their path in the ressource properties dialog and they all point to 2.7.1
Still I got errors regarding Wire.h that would not go away.

Only way to get it to compile again, was to copy over .project, .cproject, .sproject and sloeber.cfg from a local backup I luckily did just before ...


Describe your environment
sloeber product 4.4.3 on Win11

@PerennialNovice
Copy link
Author

Only way to get it to compile again, was to copy over .project, .cproject, .sproject and sloeber.cfg from a local backup I luckily did just before ...

But now I was on 2.8.1 again...
I switched to 2.7.1 and this time I immediately changed all the libraries ressource properties to point to 2.7.1 and it compiled at the first try :)
So the main issue seems to be that when switching platform verions, the libraries do not get switched as well?

@jantje
Copy link
Member

jantje commented Sep 3, 2024

So the main issue seems to be that when switching platform verions, the libraries do not get switched as well?

Indeed Libraries do not get switched out when changing the project->properties->sloeber settings.
That is why there is the menu->sloeber->reattach libraries
The same problem exists in V4 when switching configuration (where the 2 configurations require different libraries).
V5 is intended to fix the configuration change problem but the project->properties->sloeber change will still be there.

@jantje jantje changed the title not respecting platform choice with two versions of STM32 installed Sloeber does not update the hardware libraries when changing the boards.txtx (F.I. when switching between two versions of STM32 the hardware libs will point to the original STM32 libs ) Sep 3, 2024
@jantje jantje added the status: known limitation This is soimething we can live with label Sep 3, 2024
@PerennialNovice
Copy link
Author

The same problem exists in V4 when switching configuration (where the 2 configurations require different libraries).

Our projects use different libraries for AVR or STM32 target, but we never had an issue when switching. Maybe because we only had different "exclude from build" settings instead of relying on removing/adding libraries?

@jantje
Copy link
Member

jantje commented Sep 5, 2024

The exclude from build is great but can not be used in the case of different versions of a board when using "hardware libraries" as the folder with the name of the lib can only point to one versions.

@jantje
Copy link
Member

jantje commented Dec 20, 2024

Should be fixed in V5

@jantje jantje closed this as completed Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: known limitation This is soimething we can live with
Projects
None yet
Development

No branches or pull requests

2 participants