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
Hot Topic (More than 8 Replies) Has Build Process Changed Again?? (Read 11606 times)
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Has Build Process Changed Again??
Jul 5th, 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.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #1 - Jul 5th, 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.

  
Back to top
WWW  
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #2 - Jul 5th, 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.

  
Back to top
 
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #3 - Jul 5th, 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.

  
Back to top
 
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #4 - Jul 5th, 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.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #5 - Jul 5th, 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.

  
Back to top
WWW  
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #6 - Jul 5th, 2017 at 7:35pm
Print Post  
Tim@Visual Micro wrote on Jul 5th, 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.
  
Back to top
 
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #7 - Jul 5th, 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.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #8 - Jul 5th, 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 5th, 2017 at 8:40pm by Tim@Visual Micro »  
Back to top
WWW  
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #9 - Jul 5th, 2017 at 10:13pm
Print Post  
Tim@Visual Micro wrote on Jul 5th, 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.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #10 - Jul 5th, 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?

  
Back to top
WWW  
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #11 - Jul 5th, 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.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #12 - Jul 5th, 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
Select All
C:\Users\RayL\AppData\Local\Temp\VMBuilds\SuperATC\arduino_due_x_dbg\Release\Su
perATC\I2CEEPROM\I2CEEPROM.h
 


« Last Edit: Jul 5th, 2017 at 10:36pm by Tim@Visual Micro »  
Back to top
WWW  
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #13 - Jul 5th, 2017 at 10:36pm
Print Post  
Tim@Visual Micro wrote on Jul 5th, 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 5th, 2017 at 10:37pm by RayLivingston »  
Back to top
 
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #14 - Jul 5th, 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.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #15 - Jul 5th, 2017 at 11:40pm
Print Post  
what happens with deep search switched off?

Does the -I solve it?

Thanks
  
Back to top
WWW  
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #16 - Jul 5th, 2017 at 11:48pm
Print Post  
Tim@Visual Micro wrote on Jul 5th, 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.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #17 - Jul 5th, 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...



  
Back to top
WWW  
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #18 - Jul 6th, 2017 at 12:55am
Print Post  
Tim@Visual Micro wrote on Jul 5th, 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 5th, 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.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #19 - Jul 6th, 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.
  
Back to top
WWW  
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #20 - Jul 6th, 2017 at 10:35pm
Print Post  
Tim@Visual Micro wrote on Jul 6th, 2017 at 6:16pm:
The new system will be much more intelligent. It should just find everything where ever it is.


I look forward to seeing what that new system is...

Tim@Visual Micro wrote on Jul 6th, 2017 at 6:16pm:
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. 


I think I ended up with the weird paths because some of the classes in sub-directories reference other classes in sub-directories.  I would like a "cleaner" way of doing this.  I really should just ditch the whole Arduino build, and create a makefile, but I know that would turn into several days of aggravation, so it stays well down on my ToDo list.

Regards,
Ray L.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #21 - Jul 7th, 2017 at 1:37pm
Print Post  
I think you just needed to use libraries.

The recent releases of visual micro support shared projects. That's a nice way to have libraries that exist in any location. Library paths get added as -I includes so you probably wouldn't have so many issues.

http://www.visualmicro.com/post/2017/01/16/Arduino-Cross-Platform-Library-Develo...


  
Back to top
WWW  
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Has Build Process Changed Again??
Reply #22 - Jul 7th, 2017 at 2:43pm
Print Post  
Tim,

I will look into that approach.  These are, for the most part not what I think you would call "libraries".  With few exceptions, they are classes that are a part of this one large project, and would not be used anywhere else.  There are also many dependencies between many of the classes, and they are all part of a single large, heavily hierarchical application (an automatic tool changer for a CNC milling machine).  It is perfectly logical for them to be part of this project, and not part of a "shared" library in the normal Arduino sense.  But, if a different directory structure can un-tangle the seemingly fragile mess it is right now (this is the third time a tool update has broken the build), I am open to that.

Regards,
Ray L.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Has Build Process Changed Again??
Reply #23 - Jul 7th, 2017 at 3:54pm
Print Post  
Hi,

I think the only breakage was you specified a folder to access a header in the same folder. It is correct that you alter your code because it didn't make sense. When the paths you have used in your #included are correct nothing will break.

If you had preceded the path with ../ that also would have worked but it's much cleaner to remove the path from the header entirely.

You also now know how to set your own compiler -I includes so you have the capability to set things up in a known way.
  
Back to top
WWW  
IP Logged
 
Page Index Toggle Pages: [1] 
Send TopicPrint