Hi,
This sounds a little like a couple of the other recent topics, but not enough to tag on to them.

I have a shared library (RFModules it's called) that has been working for many years on the AVR, handling three types of module with a mostly common interface.  I had a demo/verification sketch for the module drivers, also had a trial build for the Heltec LoRa ESP32 device that worked and interoperated with the AVRs.  I am going to use the lib in another ESP32 project, so decided to first update the demo stuff, as the lib has had some small changes over the years, and ESP32 SPI is in flux.  All fine on the AVR, but I had all kinds of trouble getting the ESP32 to build, despite starting from code that was known to work.

Starting from an empty Arduino project/solution, there is naturally no error.  If I add the two libs (mine and SPI for ESP32) to the solution and #include them in the .ino, it starts to get strange.  Unless I configure deep search, the build fails.  I will attach the output, which shows it is trying to use at least one odd library:

Include Path 'E:\Projects\Arduino Sketchbook\libraries\STAMP-PICO\src'

(sometimes there were up to five libraries that should not have been used). That library is indeed present, but not referenced and the platform is the Heltec LoRa 32 anyway.  It has stuff in it which really messes things up.

I also notice that after such a build, the VS Program Pages C/C++ item has, in the Additional Includes setting:

es\SD\src
E:\Projects\Arduino braries\SPI\1.0\SPI\src
es\FS\src
es\SPI\src
E:\Projects\Arduino \..\..\..\libraries\STAMP-PICO\src

This varies, often it's just the last item.  Note the SD, FS and STAMP_PICO libs have no place in the project, and the (cloned) AVR SPI lib has also been included.
I have tried to edit the Additional Includes in the Property Page, but it doesn't stick.  I also tried deleting the STAMP-PICO lib, but all it does is tell me it can't find the library and fail.

How do I eliminate the unwanted includes?  Where do they even come from?  I don't want to have to do a deep search each build.

Thanks, in anticipation of your usual excellent response.
Jed

Tim,
I think you misunderstand me, or I misunderstand you.  The unwanted libs are not listed in References, and in the case of my minimal test projects, created in a new VS instance, they never were.  Nevertheless, they show up as in those two quotes in my post.  As there is no evidence (to me) of where they came from, I have no idea how to eliminate them.

My shared lib is referenced by the project, but I don't think you want me to remove that?  It doesn't build without it.

Tim,
Cleaning the solution or the project did not seem to have any effect, that I could see.

I am also now having trouble reproducing the problem.  The closest I got was that I opened up a multi-project solution (projects are down in the examples area and all are demos/tests) in a new invocation of VS.  The smallest project built OK, but the intellisense could not find my lib header, until I changed the angle brackets to quotes.  I then switched to the second project, and it could not find my lib at all.  It was not listed in the build output as an include path, though was listed in References.  I could not fix that (e.g., by removing the Reference and re-adding), so I restarted VS.  This time, all works well, so that's another thing I cannot reproduce.  Intellisense now also finds the angle bracketted header.

I have done some tests with a sketch at sketchbook level, basically the same simple demos.  I was getting the same problems with that before, but it is also working fine again.  I suppose it can be ascribed to VS and/or various caches being messed up.  I will send you the project in case you can get anything useful from it; maybe it is to do with being below the examples folder.

Thanks,
Jed

Tim,
Here are the paths:
My library:
E:\Projects\Arduino Sketchbook\RadioSignals\SharedLibraries\RFModules\RFModules.vcxitems
Project:
E:\Projects\Arduino ulesVerify.vcxproj

The SPI library in this case is cloned, so it is at:

E:\Projects\Arduino PI

Thanks for the update.

Could you ZIP and attach the whole project folder so we can test this more accurately with the same setup?

Is there a reason for disabling the vMicro > Compiler > Deep Search for Libraries + Accurate Prototype Insertion (GccE)?

If I compile with Deep Search OFF, I get the same problem, however with it turned on this seems to work as expected on my machine.

Thanks for the update.

The Deep Search has to be enabled to allow the conditional #if directives to be assessed correctly. That is one of the core benefits of deep search. Therefore, in your scenario it has to be enabled.  If it is disabled then the #if won't be recognised correctly and both libraries will be picked up for compilation, irrelevant of the board selected.

If deep search is off, libraries are discovered only from the #includes in the .ino. With deep search on the .ino and cpp files of the project and libraries are searched for #includes.

The vsarduino is not the best place to look for reference. Use "vMicro>Show hidden files" to more easily see core code and use GoTo definition to inspect toolchain code or view the toolchain source directly.

The arduino build rules for library and tool chain discovery always apply. The easiest way to avoid confusion is to keep projects away from library source folder structure. You can edit .vcproj files to alter their relative paths should you move your poject to a cleaner location.