Before logging an issue, please update to the latest release of Visual Micro from the Downloads Page.

When Logging a Support Issue in the Forum, please ensure you have also:-

  • Enabled vMicro > Compiler > Show Build Properties
  • Re-Compile your program with these settings enabled
 
Save the new Output to a Text File and....
  • Click the Reply button and attach as .txt file OR
  • Click here to Email us with the file attached, and a link to your post
Support requests without the output above may be impossible to answer, so please help us to help you
 
Page Index Toggle Pages: 1 Send TopicPrint
Normal Topic UserLibrary vs. LocalLibrary (Read 2134 times)
jirkaptr
Junior Member
**
Offline


Posts: 14
Location: CZ
Joined: Dec 14th, 2016
UserLibrary vs. LocalLibrary
Feb 28th, 2017 at 9:08am
Print Post  
Processing projects using UserLibraries and LocalLibraries I found my uploaded projects are mismatched. For this reason I have studied the behavior in detail and I present here attached results to asses.

I experimented with relation between UserLibrary and LocalLibrary only. That means I did deal neither with the Core' libraries nor AddExistingItems.

Actually I am using VS Community 2015 Update 3 and VisualMicro Version 1.1702.15.
(Setpoint Make Libraries Editable When Selected is set to "False". Is it relevant?)

  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: UserLibrary vs. LocalLibrary
Reply #1 - Feb 28th, 2017 at 11:37am
Print Post  
Hi,

I only looke quickly at your document but thank you for so much effort.

Maybe this will help...

1) Read-only library view original source

Libraries in project\src\_micro-api-readonly\libraries should be "linked" sources to the original library code. These are to make the source available for reference while writing project code.

2) Editable local libraries

Libraries in project\src\_micro-api\libraries are considered local project libraries. The source can be edited, new source code can be added to the library and the compiler will detect the changes during build.

3) new options - Shared C++ Projects to edit any library

Option 1) s useful for users who do not want to edit or change libraries but want to see the code while creating other code

Option 2) was a useful but confusing way to make editable libraries that are also local to the project

In recent releases of Visual Micro we make this much easier. We can now use standard Visual Studio C++ Shared Projects to host libraries that are located in ANY location.

This means you can edit the original of an Arduino library in sketchbook\libraries ide\libraries project\parent-folder\libraries or c:\foo\myLib

The checkbox you mentioned (Create project when adding libraries) on the Add Library menu is also new and will cause visual micro to create a C++ shared project for the selected library and add the project to the solution.

Creating a C++ shared project simply means creating a libName.vcxitems file in the selected library locatiuon

A file with a .vcxitems extension is a c++ shared project. Normal c++ projects have the .vcxproj extension.

When you add a shared library project in this way it can be added to the solution explorer and then the "References" node of the main project can be used to add the shared project as a reference to the main project.

Then you have a great environment to edit/debug any library from any location and you also have a much cleaner solution explorer where everything becomes more obvious and more standard.

Please take some time to review the draft documentation and to try a shared lib project. After you have created a shared library project you will find you can easily copy/move if you want to have a version that is unique to a project or a group of projects.

Create a shared library project

The final note about shared c++ projects is that they are standard Visual Studio projects so we are working in a way that Visual Studio understands for intellisense, yet we are still working with normal arduino libraries and we no longer need to have files below the real project which is confusing (ie: no \src\_micro-api-readonly, no \src\_micro-api)

Does this make sense?
  
Back to top
WWW  
IP Logged
 
jirkaptr
Junior Member
**
Offline


Posts: 14
Location: CZ
Joined: Dec 14th, 2016
Re: UserLibrary vs. LocalLibrary
Reply #2 - Mar 11th, 2017 at 3:03pm
Print Post  
Hi,
thanks for your replay. Unfortunately you have looked too quickly the message and thus you omitted the matter of the issues:

1.      Files nested in SolutionExplorer’s folder named  _micro-api-readonly (containing „readonly“ string) are allowed to be modified. Once they are nested in “readonly”, they must be read-only.

2.      The list of library files really used in Build process differs from the files reported and visualized in SolutionExplorer (content of SourceFiles and src folders). I observed the mismatch syndrome experimenting with Local and User libraries.
Details of both issues are demonstrated in the last message’s attachments.

A question: Let’s have (slightly) different libraries named XXX in LocalLibrary, in UserLibrary and in Core. Let’s use versions #include “XXX.h” and #include <XXX.h> in project.ino. Which library will be applied in various combinations? What are the precedencies in the choice of libraries having the same name?

Tim@Visual Micro wrote on Feb 28th, 2017 at 11:37am:
2) Editable local libraries

Libraries in project\src\_micro-api\libraries are considered local project libraries. The source can be edited, new source code can be added to the library and the compiler will detect the changes during build.

I am very happy with this feature!  The one allows me to slightly modify the generally used libraries for SPECIAL PURPOSE IN THE SPECIAL PROJECT. Another important purpose is to archive libraries TO GUARANTEE THE COMPATIBILITY of libraries WHILE REUSING the project later, because as it is known, the new versions of libraries rather often are not reverse compatible. In other words: It is necessary sometimes “de-share” a library or a file, and LocalLibrary is intended  for this. However the build process must work correctly and reliably regarding this requirement.
  
Back to top
 
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint