Hi,

Not sure I have the full picture it would be easier if you post the .vcxproj file after closing and saving the project. Then I can see what is included in the local project.

It might be that when local project headers match a library header name then the library is taking priority. We don't use the build system of the arduino ide so that could be looked at and rectified.

However if you want to work with lib style includes that don't have paths then maybe consider local project libraries. These are standard arduino libraries below the project folder in a known special folder structure so can be included in the same way as normal libs and are not part of the project code. Use the "Add Code>Create Library" to see the spcial folder structure.

Maybe of interest.. the next version allows you to use C++ shared projects which allow you to have code in multiple projects and shared as if each is directly part of the mater project.

https://blogs.msdn.microsoft.com/vcblog/2015/07/30/cross-platform-code-sharing-w...

This is odd....  I found the AdditionalIncludeDirectories under Project->Properties, but there are numerous references to sub-directories of libraries in the vxproj file that do NOT show up that field in the Project->Properties dialog....

Regards,
Ray L.

Tim,

I suppose my biggest problem is not fully understanding how it does work.  Being compatible with the Arduino IDE has not been an issue for me for years, as several of my projects are already doing things the IDE does not support, or support poorly.  The ONLY reasons I use Arduino at all are the really cheap hardware, ready availability of many useful libraries, and inertia.

It seems like every time I move a library I end up spending two hours getting the project to compile again.  It seems really odd to me that using #include with quotes would EVER find a file in the "system" library without first exhaustively searching all other locations.  But, I guess that's Arduino for you.

Truth be told, my life would be easier if I could just use a make file (I actually already HAVE a working template for a makefile), but then I'd lose the quick and easy linking to the error lines through the VS Error pane (which would be really painful) and the automatic upload of the new code to the hardware.  If there was a way to use a make file and NOT lose those capabilities, I'd probably be a happy camper.  I'd then ditch the whole setup/loop paradigm, and just write my own main(), like in the good old days.  I think the "help" the Arduino build process provides causes at least as many problems as it solves.

Quote:


That sounds like it might be a help.  Can you provide more information, or a link?

Regards,
Ray L.

Yes it's a difficult line to walk, keep some things simple but loose flexibility.

It would be useful to know why you want to work with local code instead of libraries. It makes sense for various reasons but it's important for me to understand your reasons before I make suggestions.

It's also an idea to look at the shared projects in the next release. They offer a way to separate the code into library like modules but the code is merge with the project code (hidden) during compilation. Microsoft have done a good job by the looks of it, intellisense in shared projects inherits from the (current) project that uses it so it's easy to develop.

Okay so why wasn't the local library facility I mentioned previously of use? It does exactly as you describe. You can copy a library locally and the compiler will use the local one instead of the original. 

The sources can be included in the project so easy to work with yet because they are in a special folder they remain as libraries in all other respects.

Okay so open a project and switch the solution explorer to "show all files"

Then right click and create a folder called "src"

Then create another folder below that called "_micro-api"

Then another folder below that called "libraries"

Then create a folder below "libraries" called MyTestLibrary

Put a MyTestLibrary.cpp and MyTestLibrary.h in the folder

Then in your normal project code #include "MyTestLibrary.h" as if it is a normal arduino library.

You will have created and used a local arduino library called MyTestLibrary

Then open windows explorer and navigate to the folder so you can see that the "show all files" view is simply showing the folder structure same as windows explorer.

The only difference between "show all files" and windows explorer is that you can right click the solution explorer and toggle sources in/out of the project. 

So you end up with a normal sketch project that also contains libraries

There is an update coming hopefully later today with a fix for the "Add Code>Create Arduino Library" which crashes in the last release so isn;t much help. If you can't see the menu item then maybe you are on an older visual micro build.

Sorry I am rushing and not being clear

All of the library code you have added to sub folders is no different from normal code.

HOWEVER

Using the special folder names \src\_micro-api\libraries is where the difference is. 

This is assuming you have a licensed version of visual micro and not just the free version?

Yep just as the process is altered to build libraries, which can exist in various known locations. The src\_micro-api\libraries folder simply becomes one of those locations.

Keep in mind that libraries and the core is pulled from various locations and the .ino code is combined into a single .cpp. To the arduino build happens in a temp folder which you will see if you switch on the vMicro>Compiler>Verbose and "Show build folder" properties.

So Visual Micro does treat that location in a special way. It allows you to create or overrride any arduino library whilst still maintaining compatibility with arduino in the way libraries are #included and compiled.

Quote:


It's not  bug, it is the design of Arduino.

Quote:


That's right, the build treats the "\src\_micro-api\libraries" sub folder differently.

Hi Tim,

Like @RayLivingston I am trying to understand header resolution rules for my project because like him I want to maintain project specific versions of my Arduino libraries so that I can modify them without affecting other unrelated projects.  This is a *very* common development practice.  I know vMicro is dependent on the Arduino IDE's design but can still share with users how things work in the build process, then we can adapt.  You have dropped most of the breadcrumbs above.  I guess my question is why would this not be documented in detail somewhere besides an obscure forum post?  vMicro is selling a professional product to professional users.  It is in their interest to document how that product works in a standard environment.  Most developers are pretty smart and will get it if the details are available.

To answer your question above as to *why* a developer would want project specific versions of a library consider the case that I want to encapsulate a fully independent version of my project to share with another dev machine, or a co-worker, who has no custom modifications to their build environment.  I want to be able to point Git at a folder, create a repository, post it for others to enlist in and collaborate.  This implies that when I make a change to the project and sync with Git those changes should not break the build on other machines nor require special instructions to manually change the build environment (e.g. copying libraries to Arduino IDE folders.

I think you have provided a solution in the src/_micro_api/libraries folder.  I have yet to try that.  If indeed that is the answer a blog post, release note or other discoverable document would be a huge advantage to other vMicro users.

FWIW, if I understand correctly, the VS shared projects solution does not address my scenario because the whole point is *not* to share the library outside my project thus adding dependencies and potential conflicts between projects.  I just want a local copy that I know will be used consistently.

I hope this explanation helps you/vMicro understand what I believe to be a common need among their users and allows them to make an even better product!