why with libraries you sometimes get one with -master suffix?

I have tons of duplicates, I usually just keep the newer, but golly. Do you have a good system of getting rid of duplicates or just a manually kill an hour deleting obvious unneeded files type of system?

What duplicates? The thread title has a simple answer, it’s an artifact of Github. I just rename them to remove the “-master” like everyone else.

You have to explain what it is that you’re spending hours on.

Well sometimes you download a zip file that has things like ESP8266WiFi in subfolders. now, since I don't want to delete that one now I have two copies of ESP8266WiFi in libraries. multiply that by all the stuff I might download over the course of several months and pretty soon you have duplicates everywhere.

You should never have two copies of the ESP8266WiFi library installed. I'm sure I remember us discussing this before.

The solution for unnecessary duplicates is to never create them in the first place. If you're manually installing a new version of a library, delete the old installation first. This methodical approach takes a little extra time up front, but saves much more time later by preventing the "now why the heck do I have two copies of this library with different folder names?" confusion that will inevitably come later.

Whenever possible, use Library Manager to install and update your libraries. Except in the rare case where there is a malfunction (such as your virus scanner interfering with the installation process), the old version of the library will be replaced with the update.

Or, just create a folder "Old libraries" and drag the old copies in there. Pretty soon you'll wonder why your keeping all this junk and toss it.

Unless your a hoarder. Then you'll just have to buy another hard drive.

-jim lee

I have an "old libraries" folder and an "even older libraries" folder.

Then you buy a new development system and now you have old folders from that old computer cluttering up your life with the new computer.. There's the three folders for the same project with three different related names that you forgot why you named them like that. Or what was in them? And, could I toss these or not?

Now I completely rely on github to store stuff and run it from system to system. And my desktop is still a cluttered mess.

Some days you just need to do house cleaning.

-jim lee

in the folder called libraries, I have 6440 files with the .h or .cpp extension. I guess you just hope it all works and leave it at that. I have lately gotten into the habit of putting .h and .cpp (with obscure names, not the basic ones like arduino.h) in the folder with the .ino this makes it easier when moving a folder to my laptop to recompile the program into an existing board somewhere. Two different .h files can have vastly different contents even with the same name.

sevenoutpinball:
I have lately gotten into the habit of putting .h and .cpp (with obscure names, not the basic ones like arduino.h) in the folder with the .ino

You're setting yourself up for a lot of confusion when it comes time to update the libraries by doing that. The better way to do it is put each library in the "src" subfolder of the sketch, then update your #include directives accordingly.

This allows you to bundle libraries with the sketch while keeping them completely intact and separated from each other, rather than all jumbled together along with your sketch files.

It means you don't need to worry about filename collisions between the files of different libraries, which is guaranteed to happen with the standardized filenames like README.md, library.properties, and LICENSE, which are important to keep together with the library.

So, along with all this library discussion. I have a growing dilemma with mine.

Libraries are nice, they can be plunked into any source and used. Makes perfect sense to me.

Copying libraries to your src folder… Makes so you can move the project as a block, but when the IDE updates you run the risk of “I didn’t keep this project updated and now everything has changed.” Kind of issues. Been there.

Adding .h & .cpp files specific to your project to the project folder. This works great up to a point. Then you have too many tabs on your project window. That doesn’t scroll. Uggh!

Now in my stuff I’ve come up with “panels”. These are basically Arduino applications that can be swapped in and out during runtime. Like a “real” computer. I have a calculator App, Breakout game App, Star Trek App. STerm App… I can’t call them libraries, because, to be incorporated in a project, each one needs a couple small tweaks. So I’m kinda’ at a loss as to how I file these? A growing problem because I seem to be ending up with more all the time.

-jim lee

Now in my stuff I've come up with "panels". These are basically Arduino applications that can be swapped in and out during runtime. Like a "real" computer. I have a calculator App, Breakout game App, Star Trek App. STerm App.. I can't call them libraries, because, to be incorporated in a project, each one needs a couple small tweaks. So I'm kinda' at a loss as to how I file these? A growing problem because I seem to be ending up with more all the time.

I have no idea what that means, but it sounds good.

You're setting yourself up for a lot of confusion when it comes time to update the libraries by doing that. The better way to do it is put each library in the "src" subfolder of the sketch, then update your #include directives accordingly.

This allows you to bundle libraries with the sketch while keeping them completely intact and separated from each other, rather than all jumbled together along with your sketch files.

It means you don't need to worry about filename collisions between the files of different libraries, which is guaranteed to happen with the standardized filenames like README.md, library.properties, and LICENSE, which are important to keep together with the library.

that would be better, but what I usually do is start a new program from an existing one of mine with save as. So it starts with nothing. Then out of frustration with the compiler picking one that doesn't work I find one that will and add that to the .ino directory.

Sounds like what you are suggesting is if you get a program from GitHub just put your program in with the examples and it will already have the includes.

sevenoutpinball:
I have no idea what that means, but it sounds good.

I've done that. It just means that you can load multiple code sets that are really in the same sketch, and select among them at run time, as if they were separate "apps". There are various ways of doing that.

Recently I got fed up with the code jungle in "libraries" and reduced the number of libraries allowed to be there, to only the ones that I might need this month or so.

sevenoutpinball:
Sounds like what you are suggesting is if you get a program from GitHub just put your program in with the examples and it will already have the includes.

Not at all. Let's say you have a sketch named MySketch with a folder structure like this:

MySketch
|_ MySketch.ino

Now say you want to use a library named SomeLibrary in the sketch and the library's folder structure looks like this:

SomeLibrary
|_ LICENSE
|_ README.md
|_ library.properties
|_ src
|_ SomeLibrary.cpp
|_ SomeLibrary.h

With your approach, the folder structure will now look like this:

MySketch
|_ MySketch.ino
|_ SomeLibrary.cpp
|_ SomeLibrary.h

and your #include directive in MySketch.ino will look like this:

#include "SomeLibrary.h"

With my approach, the folder structure will look something like this (depending :

MySketch
|_ MySketch.ino
|_ src
|_ SomeLibrary
|_ LICENSE
|_ README.md
|_ library.properties
|_ src
|_ SomeLibrary.cpp
|_ SomeLibrary.h

and the #include directive in MySketch.ino looks like this:

#include "src/SomeLibrary/src/SomeLibrary.h"

Now, please visualize how both of these folder structures would look as you add several other libraries to the sketch. Do you now see how your approach becomes a huge mess, while my approach stays nice and organized?

Now please visualize you want to update the SomeLibrary library. Do you see how this will be a headache with your approach, because you'll need to try to figure out which files are from the SomeLibrary library, which files are from your sketch, and which files are from other libraries. Keep in mind that the library author may add or remove files over time. With my approach, updating SomeLibrary it only requires deleting athe old MyLibrary/src/SomeLibrary folder and then adding the new version of the library in its place.

Keep in mind that complex libraries will often have subfolders, which is not even supported with your approach, whereas it will work fine with my approach.


One important thing to note though is that the Arduino IDE's File > Save as has a bug that will cause it to not save the src folder along with the sketch. File > Save works file, it's only File > Save as that has the bug.

Now, please visualize how both of these folder structures would look as you add several other libraries to the sketch. Do you now see how your approach becomes a huge mess, while my approach stays nice and organized?

Yes 100%. But, having all the files easily available at the top of the IDE to just click on is nice too. But now either way, they will not get updated with new stuff with the IDE constantly saying "updated libraries available" will they. I will have to update then manually copy the new one to the folder with the program. But I think I will start using your idea, thanks!! There have been too many times when a device that was working with one .h (like my tea5767 project) was fine till I updated from IDE and the new version had the same .h name but was not at all the original on I first used and somehow had no recollection of what one it was.

With the proliferation of boards that are different from the original Uno, this is going to be messy for a while no matter what happens I think.

One important thing to note though is that the Arduino IDE's File > Save as has a bug that will cause it to not save the src folder along with the sketch. File > Save works file, it's only File > Save as that has the bug.

Oh god, so if I have other things in a folder I have to add those manually. Probably to just do that with finder (Mac)

sevenoutpinball:
But, having all the files easily available at the top of the IDE to just click on is nice too.

For some, this could actually be not nice, because they will get confused by all the library code exposed in the Arduino IDE. However, it sounds like you benefit from being able to have quick access to the library code, so I think you have a point here.

sevenoutpinball:
But now either way, they will not get updated with new stuff with the IDE constantly saying "updated libraries available" will they. I will have to update then manually copy the new one to the folder with the program.

That's correct.

sevenoutpinball:
Oh god, so if I have other things in a folder I have to add those manually.

That's correct. This issue isn't only limited to the src subfolder. Anything in your sketch folder other than source files and the contents of the data folder (which can contain anything you like) are lost when you do a "Save as".

sevenoutpinball:
Probably to just do that with finder (Mac)

Yeah, that's the best approach. Just copy the sketch folder and everything comes along like you would expect.

I've ended up taking a different approach.

Since I'm mucking abut in libraries CONTINUOUSLY. I run two editors. The IDE for the .ino and whatever.h & .cpp files pertain to it, compiling and monitors. Then a second editor (TextWrangler) for everything else. I leave the libraries where they live, in the libraries folder, so they get the updates. Then, I can go over my projects and make sure they all still compile and run under whatever the development system is at that time. This keeps everything current. (Like paying off your credit cards on time.)

And I always wondered.. Why can't the IDE open a .h or .cpp file anywhere but in a project folder?

-jim lee

jimLee:
Then, I can go over my projects and make sure they all still compile and run under whatever the development system is at that time.

That sounds like a good candidate for a script that runs the whole process for you.

jimLee:
And I always wondered.. Why can't the IDE open a .h or .cpp file anywhere but in a project folder?

Check out the feature request and discussion here:

Ha! I was told to basically buzz of back to the forum on my last foray into the github issue list.

I see that thread starts 5 YEARS ago. Doesn't seem to be moving forward at any great pace.

What do "the powers that be" see as their hot buttons? What are they making people work on?

-jim lee

jimLee:
I was told to basically buzz of back to the forum on my last foray into the github issue list.

GitHub is used by Arduino for a distictly different different purpose than the forum, so it definitely takes a different approach. GitHub offers opportunities to collaborate with the Arduino developers on this project. These opportunities are available to everyone, regardless of where they are at in their learning journey. But we must be careful that our actions there have a net positive effect. When the developers get the time to write code, magic happens! If they spend all their time maintaining the issue tracker and reviewing low quality pull requests, there's no time left for fixing bugs and adding awesome new features to the software we all use.

I'm not directing any of that at you. I'm not familiar with the "buzz off" you mention. I'm just giving a general comment on how things work. I find that Arduino community members often have the impression that GitHub is just another forum or social media site, and so don't understand the appropriate approach. I am often frustrated when people post requests for assistance with their project on the bug trackers, where such requests don't belong, and I know they would have an answer in a matter of minutes if they only posted their question on the Arduino forum instead. So they don't even end up helping themselves!

jimLee:
What do "the powers that be" see as their hot buttons? What are they making people work on?

Well, critical bugs that affect many users are always a priority. Arduino also has long term goals that need many pieces put in place to achieve. For the last 10 years they have been working on transitioning the Arduino IDE codebase from a monolithic mass of Java that does absolutely everything (which has its roots in the Arduino IDE's origins as the Processing IDE), to being only the GUI component, which uses separate tools for all the underlying functionality. The first step in that process was the boards platform system. 10 years ago, the AVR architecture was hardcoded into the Arduino IDE. Now, the boards platform system allows boards of any architecture to be used with the Arduino IDE. I have a list of over 200 boards platforms!

The next project was moving the build system to a dedicated command line tool, arduino-builder. Now, they are working on the next phase, which is Arduino CLI. This provides all the functionality needed to install dependencies, compile, and upload Arduino sketches. So all the GUI tools, both the official Arduino IDE, Arduino Web Editor, Arduino Pro IDE, as well as third party tools can share the same tool and provide complete compatibility no matter what your preferred tool is.

This also makes the GUI code easier to contribute to and easier to maintain. There was a lot going on in the Arduino IDE code base before they started working on that.

Now you have something like a request to allow editing libraries in the Arduino IDE. The beginners have no use for this, and it could even have a harmful effect on them if it makes the learning curve of the Arduino IDE steeper by increasing the complexity of its UI. On the other side, the advanced users are happy with their advanced text editors or IDEs and have no desire to edit libraries in the Arduino IDE. So it mostly appeals to a smaller group inbetween the two extremes of the spectrum. So it's not surprising this is not treated as a high priority. Nevertheless, you can see that it is still open 5 years later, so they have not rejected the feature request. Now that Arduino is expanding their tool offering with the Pro IDE, it opens up the possibility of being able to add advanced features to that IDE, while keeping the Arduino IDE very simple and beginner friendly.