What is the correct way to handle library versioning?

I have spent a few hours googling and searching this forum on the topic and I'm still not clear how to handle "customized" or "local" libraries. Perhaps I am misunderstanding something more fundamental, if so, my apologies for the hand holding.

The library I am specifically concerned with is Adafruit_SSD1306. I need to have multiple versions of this library to handle development for different screens.

I do this currently by:

1 - specifying a Sketchbook Location in the Config Manager which contains my custom libraries.
F:\Google Drive\aurora\Arduino\
The IDE location remains at C:\Program Files (x86)\Arduino

2 - duplicating the library folder, renaming both it and the .h .cpp files. Editing the .h and .cpp files to change the declarations and other references to the new names, making the functional changes to the library code as required.

3 - including the new library in the .ino file by adding e.g.:
#include <Adafruit_SSD1306_custom64.h>

I have checked the Verbose Build Properties output and this method does seem result in the correct version of the library being called. However, I came across some references to options that I no longer see in the VM Add Library menu:

• Create Shared Project when Including Libraries
  
• Clone For Solution When Including Libraries
  
• Clone For Project When Including Libraries
  
• Use Library Version in Clones
  

And I understand that there have been some changes in the way that includes are handled where local copies of a library were/are kept in a /src folder in the sketch folder - possibly called with
# include "filename"
instead of
# include <filename>

So I am wondering if perhaps the way I am doing this is not correct or "best practice".

Many thanks.

VM 1906.12.0
Atmel 7.0.1931
IDE 1.6/1.8

I think you have switched from Visual Studio to atmel studio. Visual Micro only supports library versions and shared projects in Visual Studio because Visual Studio provides "Shared C++ Projects". Atmel works differently and we don't expect it to be supported for much longer so it's not worth the dev effort. It's based on vs2015, if atmel studio moves to the new Visual Studio Shell for either 2017 or 2019 then it would mean that our code base can be aligned once again. Currently only part of the code it aligned due to the age of as7 and the huge changes Microsoft have made since 2017.

If you used Visual Studio and shared library projects that works well for versioning. Shared libraries can exist in any folder, therefore you just have to come up with a nme convention that allows a version to be applied, then add a "shared project reference" from an arduino project to lib version_X. This would means that all of the #includes remain the same, only the library path changes.

Thanks for the very quick response - I missed the notification somehow. Ok - switching to Visual Studio is fine.

Following your post I read I read Including External Files and Arduino Shared Cross-Platform Code And Library Development

To better understand


Quote:

come up with a nme convention

That would be name convention I presume?

Do I understand correctly that when you say
Quote:

all of the #includes remain the same

you mean that:
 - I can keep the name of the library referenced in the include the same e.g.:  #include <spi.h>
- duplicate and change the spi library folder name e.g.: spi_verXX
- modify the library code but leave the filenames and references unchanged
- add the modified library to the project using Add Library with the "Create Shared Project When Including Libraries" option checked?


Many thanks

Actually I forgot that there is an old way to create local libraries below the project I think in a libraries folder but it is more difficult to support.



Quote:

- I can keep the name of the library referenced in the include the same? e.g.:

#include <spi.h>


Quote:

Yes you can use same header names but do not have too. Ideally the name of a library folder shoould contain a header with same name but it's not ciritical.

MyLibraries\Lib1\v1x1\Lib1
MyLibraries\Lib1\v1x1\Lib1\library.properties
MyLibraries\Lib1\v1x1\Lib1\Src\Lib1.h

When you right click references in your Arduino project and add a "Shared Project" reference to your library this allows Visual Micro to use whatever libraries you have included as a preference to any other Arduino libraries so it is all within your control.


Quote:

- duplicate and change the spi library folder name e.g.: spi_verXX?

Yes


Quote:

- modify the library code but leave the filenames and references unchanged?

Up to you. If other libraries you use that are not editable shared projects also reference the library then you might want to use the same name to avoid confusion. For example if some other library you reference expects spi.h and you changed your copy of spi to something else then the spi library would be used in addition to your something else. It can be confusing but okay if you work in a clean manner hich might be making a copy of all libraries.


Quote:

- add the modified library to the project using Add Library with the "Create Shared Project When Including Libraries" option checked?

The visual micro "add lib" menu is just to show you what to create and do. It doesnt do anything special behind the scenes. If you have a shared project and click that standard visual studio "Add Project" commands to add a shared library project to the solution then add a reference into your "arduino project > references" list and added one or more code #includes to your library then you have done manually what visual micro does.

Final Note

The system is simple enough that you can use the standard VS File>New>Project dialog to create a new "Microsoft C++ Shared Code Project" unrelated to Visual Micro.

If you then add the library.properties, source code in the structure outlined here and then add the Reference from an Arduino project to the Shared Project. That has same end result, Visual Micro will treat the shared project as a standard Arduino library.

Thanks for the clarifications. Greatly appreciated.
I will give this a try.