VS Arduino - Has Build Process Changed Again??

May 23^rd, 2025 at 10:51am (UTC)

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

VS Arduino › › › Has Build Process Changed Again??

‹ Previous Topic | Next Topic ›

Page Index Toggle

Pages: [1] 2

Hot Topic (More than 8 Replies)

Has Build Process Changed Again?? (Read 13212 times)

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Has Build Process Changed Again?? Jul 5^th, 2017 at 3:51pm	Print Post
	I have a massive project that was working just fine on my old PC, using IDE v1.8.1 and Due v1.6.4. On my new PC I've installed IDE v1.6.2 and Due v1.6.11, and I am getting TONS of errors for include files not found. Every one of the includes it says it can't find ARE copied to the build directory. AFAICT, ALL of these are includes that are in a sub-directory of the project directory, so I suspect something has changes, or it broken, in the way includes are being handled. Here is the first of the long list of errors I get: Building project code ... ATCConfig_v0_04.h: 6:33: fatal error: I2CEEPROM\I2CEEPROM.h: No such file or directory #include "I2CEEPROM\I2CEEPROM.h" compilation terminated The project is "SuperATC". ATCConfig_v_0.0.h/.cpp are in SuperATC/ATCConfig, and I2CEEPROM.h/.cpp are in SuperATC/I2CEEPROM, and they, along with all the dozens of other libraries ARE properly copied in their sub-directories into the build directory. As I said, this project built fine on my old PC, so why am I getting errors on the new PC? Has the v1.8.2 IDE changed, or has something changed in the current version of VisualMicro? I am running vmicro v1.1702.15 under VS2017. Regards, Ray L.


	IP Logged

Tim@Visual Micro Administrator Offline Posts: 12188 Location: United Kingdom Joined: Apr 10^th, 2010	Re: Has Build Process Changed Again?? Reply #1 - Jul 5^th, 2017 at 4:21pm	Print Post
	You don't say which vm version you used to use so I can't answer what has changed. It might not help but I do suggest installing the same versions of arduino that you were using before. This will avoid some confusion and need for concern about what might have changed in the arduino world. You can only have one 1.6/1.8 installed at a time and in any case should be pretty much the same. You haven't said which board you use because that can affect where the hardware is installed and where it is being found. There is a new deep search library discovery that was designed as part of 1.6.9 but visual micro allows it to be optional. You can switch it off on the vMicro>compiler menu. I suggest you switch on verbose and show build properties then post the output so we can see what is happening.


	WWW Facebook Twitter YouTube IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #2 - Jul 5^th, 2017 at 5:02pm	Print Post
	Tim, I don't know which VM version I was using, and that PC is now dead, so no way to find out, unless there is a way to tell from a disk image (I can't boot the machine, but can read the HDD). It was relatively current (within the last 6 months for sure). As I indicated, I am currently using a Due with v1.6.11 board package, but was using 1.6.4 on the old machine. It is the deep search that is failing. If I turn on Stop on Error, I get the below, even though the files DO exist and they ARE copied to the build directory. Searching for libraries ... 4.8.3-2014q1\bin\arm-none-eabi-g++" -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -w -x c++ -E -CC -mcpu=cortex-m3 -mthumb -DF_CPU=84000000L -DARDUINO=10802 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON -DUSB_MANUFACTURER="\"Arduino LLC\"" -DUSB_PRODUCT="\"Arduino Due\"" stem/libsam" stem/CMSIS/CMSIS/Include/" stem/CMSIS/Device/ATMEL/" res\arduino" riants\arduino_due_x" perATC.cpp" -o "nul" 4.8.3-2014q1\bin\arm-none-eabi-g++" -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -w -x c++ -E -CC -mcpu=cortex-m3 -mthumb -DF_CPU=84000000L -DARDUINO=10802 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON -DUSB_MANUFACTURER="\"Arduino LLC\"" -DUSB_PRODUCT="\"Arduino Due\"" stem/libsam" stem/CMSIS/CMSIS/Include/" stem/CMSIS/Device/ATMEL/" res\arduino" riants\arduino_due_x" perATC.cpp" -o "nul" 4.8.3-2014q1\bin\arm-none-eabi-g++" -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -w -x c++ -E -CC -mcpu=cortex-m3 -mthumb -DF_CPU=84000000L -DARDUINO=10802 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON -DUSB_MANUFACTURER="\"Arduino LLC\"" -DUSB_PRODUCT="\"Arduino Due\"" stem/libsam" stem/CMSIS/CMSIS/Include/" stem/CMSIS/Device/ATMEL/" res\arduino" riants\arduino_due_x" braries\Wire\src" perATC.cpp" -o "nul" 4.8.3-2014q1\bin\arm-none-eabi-g++" -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -w -x c++ -E -CC -mcpu=cortex-m3 -mthumb -DF_CPU=84000000L -DARDUINO=10802 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON -DUSB_MANUFACTURER="\"Arduino LLC\"" -DUSB_PRODUCT="\"Arduino Due\"" stem/libsam" stem/CMSIS/CMSIS/Include/" stem/CMSIS/Device/ATMEL/" res\arduino" riants\arduino_due_x" braries\Wire\src" perATC.cpp" -o "nul" SuperATCDef.h:4: In file included from SuperATC.ino: from ATCConfig_v0_04.h: 6:33: fatal error: I2CEEPROM\I2CEEPROM.h: No such file or directory #include "I2CEEPROM\I2CEEPROM.h" compilation terminated An error was encountered during the 'Deep Search' library discovery process. Build failed for project 'SuperATC' Regards, Ray L.


	IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #3 - Jul 5^th, 2017 at 6:41pm	Print Post
	Clearly the way include paths are resolved has changed.. Here's what's happening: This project has a .ino file in the project directory. It has dozens of libraries, most of which are in sub-directories of the project directory. Some of those libraries reference include files in the project directory or other libraries in sub-directories of the project directory. THESE are failing to resolve. For example: SuperATC.ino #include's SuperATCDef.h, which is in the project directory SuperATCDef.h #includes ATCconfig/ATCConfig_v0_04.h. ATCConfig is in SuperATC/ATCConfig ATCConfig/ACTConfig_v0_04.h DOES exist, and IS found, and #includes "I2CEEPROM/I2CEEPROM.h" SuperATC/I2CEEPROM/I2CEEPROM.h DOES exist, but is not found. If I change the #include path to "../I2CEEPROM/I2CEEPROM.h", then that error is resolved, and another one pops up. There are probably, at a minimum, dozens of instances of this kind of error in the whole project. I can, of course, fix these one-by-one (which would easily take hours), but this was not necessary in the previous version I used, so something has clearly changed. Seems like this should be the whole point of the "deep search", no? It appears the compile of the libraries is being done with their directory as the "home" directory of the compile, but shouldn't all needed external libraries be included with -I on the compile command lines to resolve this? Is there a setting I'm missing, is this a bug, or something else? This directory structure has been this way for probably two years, but this is not the first time that updating the IDE or VM has broken the build which is why I avoid updates unless I have no choice (as is the case now). Regards, Ray L.


	IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #4 - Jul 5^th, 2017 at 6:44pm	Print Post
	Alternatively.... Is there some way to make the "user" libraries folder point to the project folder, instead of \Users]\RayL\Documents\Arduino\libraries? I realize that would require copying/sym-linking any libraries I'm using from \Users]\RayL\Documents\Arduino\libraries into the project library, but I could live with that, and it should eliminate all the sillly Arduino pathing hocus pocus that seems so fragile. Regards, Ray L.


	IP Logged

Tim@Visual Micro Administrator Offline Posts: 12188 Location: United Kingdom Joined: Apr 10^th, 2010	Re: Has Build Process Changed Again?? Reply #5 - Jul 5^th, 2017 at 6:58pm	Print Post
	What libraries? You haven't mentioned any. All you have said is that you have project code "I2CEEPROM/I2CEEPROM.h" If you have files in sub folder(s) or the project and DO also have them "included" in the project solution explorer tree then we will be expecting a non-library compile for that code. If you have not "included" them in project tree then they might not be found during compile. That might be your problem.


	WWW Facebook Twitter YouTube IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #6 - Jul 5^th, 2017 at 7:35pm	Print Post
	Tim@Visual Micro wrote on Jul 5^th, 2017 at 6:58pm: What libraries? You haven't mentioned any. All you have said is that you have project code "I2CEEPROM/I2CEEPROM.h" If you have files in sub folder(s) or the project and DO also have them "included" in the project solution explorer tree then we will be expecting a non-library compile for that code. If you have not "included" them in project tree then they might not be found during compile. That might be your problem. I have numerous libraries/classes call them what you will, that get built into this project, each consisting of a .h and a.cpp in their own sub-directory of the project directory. I could just as easily have put them in my Documents/Arduino/libraries tree, but prefer to keep this project more self-contained. I DO have them all included in the project solution explorer tree. I AM expecting each of these to be separately compiled (as they were on my old PC), then linked into the SuperATC project binary. Again, this was ALL working as-is on my old PC. I'm using a direct copy of the project directory, including it's dozens of subdirectories/libraries/classes, including copies of all the VisualStudio project files contained in the project directory. In terms of there structure, contents, and configuration of the project and ALL of its dependencies, everything is exactly as it was on my old PC, as it has been for at least a year. Only the IDE version has changed (from 1.8.1 to 1.8.2), and the VM version has changed (from what version I don't know, but it is now 1.1702.15, which was downloaded and installed from visualmicro.com a few days ago). So, the build process MUST have changed, no? As far as I can tell, nothing has chanfged on my side, yet a project that was building a week ago, is now generating dozens of "file not found" errors, which seems to me like either a clear bug, or something in the build process has changed. Regards, Ray L.


	IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #7 - Jul 5^th, 2017 at 8:00pm	Print Post
	Shouldn't the project directory be included as a -I on the compiler command line, so it can find all the include files in sub-directories of the project directory? This must have been happening in the previous version I was running. In every case I've looked at so far, the problem is a reference to a .h file in a subdirectory of the project directory. In every case, the files ARE there, and ARE copied correctly to the build directory, but the compiler does not find them. The compiler is clearly NOT looking within the project directory to resolve #includes. Regards, Ray L.


	IP Logged

Tim@Visual Micro Administrator Offline Posts: 12188 Location: United Kingdom Joined: Apr 10^th, 2010	Re: Has Build Process Changed Again?? Reply #8 - Jul 5^th, 2017 at 8:39pm	Print Post
	Well for a short time in the past it used to be included but it wasn't how arduino worked and caused a lot of confusion. People expected the .cpp files in the "search path" to be compiled, not jut the headers being discovered. It's always been the case that .cpp files will only be compiled when included within the arduino and/or visual micro published rules. Having said that arduino have come up with a better way to discover everything that needs to be compiled so visual micro will shortly improve in this area. You should include all the files in the project tree that you want the compile to find. + I think you can add the -I switch yourself to the project properties global flags using the special {build.project_path} variable (F4 project settings in VS) -I{build.project_path}
	« Last Edit: Jul 5^th, 2017 at 8:40pm by Tim@Visual Micro »

	WWW Facebook Twitter YouTube IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #9 - Jul 5^th, 2017 at 10:13pm	Print Post
	Tim@Visual Micro wrote on Jul 5^th, 2017 at 8:39pm: You should include all the files in the project tree that you want the compile to find. Once again, ALL of these files ARE in the project tree, and always have been. WHY is it suddenly not working?? They WERE being found, but now they are not, and nothing has changed but the IDE version (1.8.1 to 1.8.2) and the VM version. What has changed in the IDE or VM to break this project, and is there a way to fix it, without a massive re-factoring of my code? Regards, Ray L.


	IP Logged

Tim@Visual Micro Administrator Offline Posts: 12188 Location: United Kingdom Joined: Apr 10^th, 2010	Re: Has Build Process Changed Again?? Reply #10 - Jul 5^th, 2017 at 10:29pm	Print Post
	No it hasn't changed and should work. Are you sure you have the project tree filtered and NOT viewing all files on disk? There is a small icon above the solution explorer that switches between show all files and filtered view The issue is happening during deep search for includes, did you read my earlier message about switching that off as a test?


	WWW Facebook Twitter YouTube IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #11 - Jul 5^th, 2017 at 10:30pm	Print Post
	Here is a trivial example that demonstrates exactly the failure I'm seeing: BugExample.ino, in Sketchbook\BugExample: #include "I2CEEPROM/I2CEEPROM.h" I2CEEPROM eeprom; void setup() { eeprom = new I2CEEPROM(); eeprom->begin(); } void loop() { } I2CEEPROM.h, in in Sketchbook\BugExample\I2CEEPROM: #ifndef I2CEEPROM_H #define I2CEEPROM_H #include <Arduino.h> class I2CEEPROM { public: I2CEEPROM(); void begin(); }; #endif I2CEEPROM.cpp, in in Sketchbook\BugExample\I2CEEPROM: #include "I2CEEPROM\I2CEEPROM.h" /******************************************* * Supports Atmel AT24C32/64 I2C EEPROMs *******************************************/ I2CEEPROM::I2CEEPROM() { Serial.println("I2CEEPROM()"); } void I2CEEPROM::begin() { Serial.println("I2CEEPROM.begin()"); } I2CEEPROM.h and I2CEEPROM.cpp ARE in the visual studio project tree. Build fails: I2CEEPROM.cpp: 1:33: fatal error: I2CEEPROM\I2CEEPROM.h: No such file or directory #include "I2CEEPROM\I2CEEPROM.h" Regards, Ray L.


	IP Logged

Tim@Visual Micro Administrator Offline Posts: 12188 Location: United Kingdom Joined: Apr 10^th, 2010	Re: Has Build Process Changed Again?? Reply #12 - Jul 5^th, 2017 at 10:34pm	Print Post
	Okay. 1) is your solution explorer showing all files? if so click the icon so you see filtered view. Are the I2CEEPROM sources in the project? 2) Can you see if you have a file called Code C:\Users\RayL\AppData\Local\Temp\VMBuilds\SuperATC\arduino_due_x_dbg\Release\Su perATC\I2CEEPROM\I2CEEPROM.h
	« Last Edit: Jul 5^th, 2017 at 10:36pm by Tim@Visual Micro »

	WWW Facebook Twitter YouTube IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #13 - Jul 5^th, 2017 at 10:36pm	Print Post
	Tim@Visual Micro wrote on Jul 5^th, 2017 at 10:29pm: No it hasn't changed and should work. Are you sure you have the project tree filtered and NOT viewing all files on disk? There is a small icon above the solution explorer that switches between show all files and filtered view The issue is happening during deep search for includes, did you read my earlier message about switching that off as a test? I am NOT showing All Files. It makes no difference whether Deep Search is on or off or whether All Files is on or off. The result is the same. See the simple example I just posted. The only way I've found to make it compile is to change the include path in I2CEEPROM.h to either of: #include "I2CEEPROM.h" or #include "../I2CEEPROM/I2CEEPROM.h" With the previous version, it worked with the #include as-is. Regards, Ray L.
	« Last Edit: Jul 5^th, 2017 at 10:37pm by RayLivingston »

	IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #14 - Jul 5^th, 2017 at 11:17pm	Print Post
	BTW - One other thing that changed - the old PC was running VS2015, the new one is running VS2017. Regards, Ray L.


	IP Logged

Tim@Visual Micro Administrator Offline Posts: 12188 Location: United Kingdom Joined: Apr 10^th, 2010	Re: Has Build Process Changed Again?? Reply #15 - Jul 5^th, 2017 at 11:40pm	Print Post
	what happens with deep search switched off? Does the -I solve it? Thanks


	WWW Facebook Twitter YouTube IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #16 - Jul 5^th, 2017 at 11:48pm	Print Post
	Tim@Visual Micro wrote on Jul 5^th, 2017 at 11:40pm: what happens with deep search switched off? Does the -I solve it? Thanks I get exactly the same result with deep search on or off. I tried adding the project directory to the include path in VS project properties, and it had no effect - the compiler command line was unchanged. Did you try my example? Regards, Ray L.


	IP Logged

Tim@Visual Micro Administrator Offline Posts: 12188 Location: United Kingdom Joined: Apr 10^th, 2010	Re: Has Build Process Changed Again?? Reply #17 - Jul 5^th, 2017 at 11:56pm	Print Post
	I'm sure your example would fail for me too I would expect the header to be in a folder below where the cpp is located \i2ceeprom\i2ceeprom\i2deeprom.cpp The visual micro F4 project properties are documented in the visual micro docs. Visual studio property pages are a different thing. http://www.visualmicro.com/page/User-Guide.aspx?doc=Project-Properties-Reference...


	WWW Facebook Twitter YouTube IP Logged

RayLivingston Full Member Offline Posts: 158 Location: California Joined: Nov 24^th, 2012	Re: Has Build Process Changed Again?? Reply #18 - Jul 6^th, 2017 at 12:55am	Print Post
	Tim@Visual Micro wrote on Jul 5^th, 2017 at 11:56pm: I'm sure your example would fail for me too I would expect the header to be in a folder below where the cpp is located \i2ceeprom\i2ceeprom\i2deeprom.cpp I can't argue it makes sense, but it has worked for 12-18 months, since you told me to do it that way... Tim@Visual Micro wrote on Jul 5^th, 2017 at 11:56pm: The visual micro F4 project properties are documented in the visual micro docs. Visual studio property pages are a different thing. http://www.visualmicro.com/page/User-Guide.aspx?doc=Project-Properties-Reference... OK, I misunderstood your suggestion. Yes, adding the project directory path there does resolve the problem, and it now builds. But why? I never set that on the old PC. You mentioned some changes in the Arduino build process that you will be adopting. What is that, and will it bite me when it happens? This is, IIRC, the third time a version update has broken this, and other, projects. I'm getting a little gun-shy when it comes to updates. Is there, or will there be, a cleaner, more robust way of dealing with a large number of project-specific classes in this kind of directory structure, or at least some way to put them under a common directory OTHER than Arduino/libraries? Regards, Ray L.


	IP Logged

Tim@Visual Micro Administrator Offline Posts: 12188 Location: United Kingdom Joined: Apr 10^th, 2010	Re: Has Build Process Changed Again?? Reply #19 - Jul 6^th, 2017 at 6:16pm	Print Post
	The new system will be much more intelligent. It should just find everything where ever it is. I think there might have been some confusion. for example, If you wanted to reference from a project level .ino or .cpp to a .h in a sub folder I would have told you to add a path qualifier. Otherwise if in the same folder no path. When adding libraries, due to the way arduino works, we allow one level of path for headers which specifies a unique lib name. This is useful when the same headers exist in two different libs. It worked because the project folder did used to be added as a search path but because arduino did not work this way and many users don't understand what gets compiled it's better to keep is clean, less support and breakage for all but a few users. Sorry you got caught.


	WWW Facebook Twitter YouTube IP Logged

Page Index Toggle

Pages: [1] 2

‹ Previous Topic | Next Topic ›

« Board Index ‹ Board Top

Top

VS Arduino » Powered by YaBB 2.6.12!
YaBB Forum Software © 2000-2025. All Rights Reserved.