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
Locked Topic How to reference #defines created in a project from library code - SOLVED (Read 4894 times)
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
How to reference #defines created in a project from library code - SOLVED
Jul 25th, 2018 at 4:13am
 
I am working on two sketches (Transmitter and Receiver) that communicate over nRF24L01 WiFi. I developed one class (BJRH24SendReceive) that supports both sketches. I am getting very strange compiler behavior with both sketches: one has 10 errors that look like this:

<code>Severity      Code      Description      File      Line
Error            undefined reference to BJBufferManager  BJBufferManager(unsigned int)      Test_Transmitter.ino      65</code>

It is looking for BJBufferManager, but if I hold the mouse over the bad code, it clearly finds BJBudderManager.

The other module produces a bunch of errors that look like this:

<code>BJRF24SendReceive.cpp: 67:19: error: 'WIFI_POWER_LEVEL' was not declared in this scope
   radio.setPALevel(WIFI_POWER_LEVEL)</code>

WIFI_POWER_LEVEL is also defined - I hover the mouse over it and the value and comments are displayed. 

The Compiler output for both of these is attached. Love any ideas you may have.
« Last Edit: Jul 27th, 2018 at 7:22pm by Tim@Visual Micro »  

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: Strange Compiler Behaviors
Reply #1 - Jul 25th, 2018 at 4:21pm
 
I guess the errors you have shown in your post are intellisense errors. as you know you should ignore them and use the build output to report errors.

I suggest you go through the links to libraries and ensure the expected libraries are being found in the expected location. It's possible your chosen libraries and code expects certain versions so let's have a clear understand of what you expect.

Code
Select All
Building core ...

Building libraries ...
"D:\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -Wall -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -flto -mmcu=atmega328p  -I"D:\Documents\Arduino\Communications\nRF24L01\nRF24L01_Test_Receiver" -DVM_DEBUG_BREAKPAUSE -DVM_DEBUGGER_TYPE=VM_DEBUGGER_TYPE_HARDWARESERIAL -DVM_DEBUGGER_TYPE_SERIALUSB=18 -DVM_DEBUGGER_TYPE_USBAPI=17 -DVM_DEBUGGER_TYPE_NET_UDP=16 -DVM_DEBUGGER_TYPE_HARDWARESERIAL3=15 -DVM_DEBUGGER_TYPE_HARDWARESERIAL2=14 -DVM_DEBUGGER_TYPE_HARDWARESERIAL1=13 -DVM_DEBUGGER_TYPE_CDCSerialClass=12 -DVM_DEBUGGER_TYPE_COSA=11 -DVM_DEBUGGER_TYPE_Uart=10 -DVM_DEBUGGER_TYPE_NET_CONSOLE=9 -DVM_DEBUGGER_TYPE_TTYUART=8 -DVM_DEBUGGER_TYPE_USBSERIAL=7 -DVM_DEBUGGER_TYPE_USART=6 -DVM_DEBUGGER_TYPE_UART=5 -DVM_DEBUGGER_TYPE_TEENSY=4 -DVM_DEBUGGER_TYPE_USB=3 -DVM_DEBUGGER_TYPE_FASTSERIAL=2 -DVM_DEBUGGER_TYPE_SOFTWARESERIAL=1 -DVM_DEBUGGER_TYPE_HARDWARESERIAL=0 -DVM_DEBUG_BANDWIDTH_THROTTLE_MS=33 -DVM_DEBUG_ENABLE=1 -DVM_DEBUG -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR -I"D:\Arduino\hardware\arduino\avr\cores\arduino" -I"D:\Arduino\hardware\arduino\avr\variants\eightanaloginputs" -I"D:\Documents\Arduino\libraries\BJBufferManager\src" -I"D:\Documents\Arduino\libraries\BJRF24SendReceive\src" -I"D:\Documents\Arduino\libraries\RF24" -I"D:\Arduino\hardware\arduino\avr\libraries\SPI\src" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG" -I"D:\Arduino\libraries" -I"D:\Documents\Arduino\libraries" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers" -I"D:\Arduino\hardware\arduino\avr\libraries" "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG\VM_DBG.cpp" -o 8\Debug\VM_DBG\VM_DBG.cpp.o"
"D:\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -Wall -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -flto -mmcu=atmega328p  -I"D:\Documents\Arduino\Communications\nRF24L01\nRF24L01_Test_Receiver" -DVM_DEBUG_BREAKPAUSE -DVM_DEBUGGER_TYPE=VM_DEBUGGER_TYPE_HARDWARESERIAL -DVM_DEBUGGER_TYPE_SERIALUSB=18 -DVM_DEBUGGER_TYPE_USBAPI=17 -DVM_DEBUGGER_TYPE_NET_UDP=16 -DVM_DEBUGGER_TYPE_HARDWARESERIAL3=15 -DVM_DEBUGGER_TYPE_HARDWARESERIAL2=14 -DVM_DEBUGGER_TYPE_HARDWARESERIAL1=13 -DVM_DEBUGGER_TYPE_CDCSerialClass=12 -DVM_DEBUGGER_TYPE_COSA=11 -DVM_DEBUGGER_TYPE_Uart=10 -DVM_DEBUGGER_TYPE_NET_CONSOLE=9 -DVM_DEBUGGER_TYPE_TTYUART=8 -DVM_DEBUGGER_TYPE_USBSERIAL=7 -DVM_DEBUGGER_TYPE_USART=6 -DVM_DEBUGGER_TYPE_UART=5 -DVM_DEBUGGER_TYPE_TEENSY=4 -DVM_DEBUGGER_TYPE_USB=3 -DVM_DEBUGGER_TYPE_FASTSERIAL=2 -DVM_DEBUGGER_TYPE_SOFTWARESERIAL=1 -DVM_DEBUGGER_TYPE_HARDWARESERIAL=0 -DVM_DEBUG_BANDWIDTH_THROTTLE_MS=33 -DVM_DEBUG_ENABLE=1 -DVM_DEBUG -DF_CPU=16000000L -DARDUINO=10805 -DARDUINO_AVR_NANO -DARDUINO_ARCH_AVR -I"D:\Arduino\hardware\arduino\avr\cores\arduino" -I"D:\Arduino\hardware\arduino\avr\variants\eightanaloginputs" -I"D:\Documents\Arduino\libraries\BJBufferManager\src" -I"D:\Documents\Arduino\libraries\BJRF24SendReceive\src" -I"D:\Documents\Arduino\libraries\RF24" -I"D:\Arduino\hardware\arduino\avr\libraries\SPI\src" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG" -I"D:\Arduino\libraries" -I"D:\Documents\Arduino\libraries" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers" -I"D:\Arduino\hardware\arduino\avr\libraries" "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG\VM_mem_check_sam.cpp" -o 8\Debug\VM_DBG\VM_mem_check_sam.cpp.o"

Using library BJBufferManager version 1.0.0 in folder "file:///D:/Documents/Arduino/libraries/BJBufferManager"
  Using previously compiled file: \Debug\BJBufferManager\BJBufferManager.cpp.o

Using library BJRF24SendReceive version 1.0.0 in folder "file:///D:/Documents/Arduino/libraries/BJRF24SendReceive"
"D:\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -Wall -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -flto -mmcu=atmega328p  -I"D:\Documents\Arduino\Communications\nRF24L01\nRF24L01_Test_Receiver" -DVM_DEBUG_BREAKPAUSE -I"D:\Arduino\hardware\arduino\avr\variants\eightanaloginputs" -I"D:\Documents\Arduino\libraries\BJBufferManager\src" -I"D:\Documents\Arduino\libraries\BJRF24SendReceive\src" -I"D:\Documents\Arduino\libraries\RF24" -I"D:\Arduino\hardware\arduino\avr\libraries\SPI\src" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers\VM_DBG" -I"D:\Arduino\libraries" -I"D:\Documents\Arduino\libraries" -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\pd4xo3tv.r1p\Micro Platforms\default\debuggers" -I"D:\Arduino\hardware\arduino\avr\libraries" "D:\Documents\Arduino\libraries\BJRF24SendReceive\src\BJRF24SendReceive.cpp" -o 8\Debug\BJRF24SendReceive\BJRF24SendReceive.cpp.o"

BJRF24SendReceive.cpp:6: In file included from

BJRF24SendReceive.h: 34:31: error: 'WIFI_CONTROLLER_ADDRESS' was not declared in this scope
   byte controllerAddress[6] = WIFI_CONTROLLER_ADDRESS

BJRF24SendReceive.h: 35:26: error: 'WIFI_ROBOT_ADDRESS' was not declared in this scope
   byte robotAddress[6] = WIFI_ROBOT_ADDRESS

BJRF24SendReceive.h: 36:34: error: 'WIFI_RECEIVE_TIMEOUT' was not declared in this scope
   unsigned long receiveTimeout = WIFI_RECEIVE_TIMEOUT

Using library RF24 version 1.3.1 in folder "file:///D:/Documents/Arduino/libraries/RF24"
  Using previously compiled file: \Debug\RF24\RF24.cpp.o

Using library SPI version 1.0 in folder "file:///D:/Arduino/hardware/arduino/avr/libraries/SPI"

  Using previously compiled file: \Debug\SPI\SPI.cpp.o
Error compiling libraries
BJRF24SendReceive.h: 64:21: error: 'WIFI_CE_PIN' was not declared in this scope
Debug build failed for project 'nRF24L01_Test_Receiver'
   RF24 radio = RF24(WIFI_CE_PIN, WIFI_CSN_PIN)

BJRF24SendReceive.h: 64:34: error: 'WIFI_CSN_PIN' was not declared in this scope
   RF24 radio = RF24(WIFI_CE_PIN, WIFI_CSN_PIN)
BJRF24SendReceive.cpp: In member  

« Last Edit: Jul 25th, 2018 at 4:22pm by Tim@Visual Micro »  
Back to top
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #2 - Jul 25th, 2018 at 8:11pm
 
Tim,

I tried compiling the same code with the Arduino IDE and VS/VM and came up with radically different results. There are three .txt files in the ZIP file:

  • Arduino IDE Compiler Output.txt
    Visual Micro Compiler Output.txt
    Combined Compiler Errors.txt <-- Shows the different errors detected by each


One reply on the Arduino Forum suggested that I the "project output of tree /F /A", but I have no idea what that means or how to accomplish it. I will continue pounding on this code, but I am pretty stumped about what is happening.

Thanks,

Bob Jones
  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #3 - Jul 25th, 2018 at 8:45pm
 
I thought that a screen shot may help. The attached shows both the successful declaration of the BJBufferManager and BJRF24SendReceive objects (see lines 11-12) and their unsuccessful use (see lines 23++).

I will post one more image of the Solution Explorer panel.



  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #4 - Jul 25th, 2018 at 8:46pm
 
Here is one more image showing the Solution Explorer contents.
  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #5 - Jul 25th, 2018 at 8:55pm
 
Tim,

I have compiled both with and without IntelliSense. The same errors occur either way. I have checked and rechecked the referenced libraries and they are good. 

And I still get different errors when I compile the same code using the Arduino IDE vs. VS/VM code.

Bob
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Strange Compiler Behaviors
Reply #6 - Jul 25th, 2018 at 8:57pm
 
Let me see if I can sum things up?

  • You have an arduino project and some libraries that you have created
  • You are getting errors in one or more of your libraries that reference missing defines such as 'WIFI_CONTROLLER_ADDRESS' 
  • You have a header file in your arduino project where you have #defined all the variables that are reported as missing in your library

Is this correct?
« Last Edit: Jul 25th, 2018 at 8:57pm by Tim@Visual Micro »  
Back to top
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #7 - Jul 25th, 2018 at 9:12pm
 
Close, but not completely accurate.

I am including two libraries that I have created (the BJ... ones) plus two others (SPI and RF24).

The errors are happening in the .INO file, not in the libraries. The errors are different in the Arduino IDE than in the VS/VM ide.

The defines all come from a file that is included in the .INO file. I have proven that each of these defines is recognized successfully by the VS/VM compiler, but have not made the same proof of the Arduino IDE.

Your third assumption is correct.



  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Strange Compiler Behaviors
Reply #8 - Jul 25th, 2018 at 9:26pm
 
Yes I know you are using some other libs too but the errors relate only to your code.

I posted a clear error for you earlier. which came from the real build output window and not the  Errors List which is hard to read.

My recommendation is to close the Errors List and never open it again. With the output window you will have something that is close to what the arduino ide will produce.

As I have stated the error clearly shows that a #define from your project header file is not available in your library code.

You have said you can see your defines in your project but that is because you have header file that creates the defines in the project. The file is RemoteControllerDefinition.h

So the problem put simply is that #defines from project\RemoteControllerDefinition.h are unavailable in a library code BJBufferManager\BJBufferManager.h

That is correct. An Arduino library has no access to project code. It's a basic rule.

In the BJBufferManager.h you have commented a previous attempt to #include RemoteControllerDefinition.h. That attempt would have failed intellisense parsing and also the build would fail objecting to a missing RemoteControllerDefinition.h. Vs shows you it can find your #defines without need for #include because it assumes the code will build as one program but libs are separate.

Solution

You should un-comment the #include in BJBufferManager.h but change it to this:- 
Code
Select All
#include <RemoteControllerDefinition.h> 



Then add a compiler include for the project folder as follows using "project property>extra flags". No need to hard code a path use the build {variable}:- 
Code
Select All
-I"{sketch_path}" 












  
Back to top
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #9 - Jul 26th, 2018 at 3:16am
 
Tim,

Thanks for the extensive feedback, but I still have a problem. Actually two problems. I put together a test case to prove or disprove your assertion that defines included in a sketch are not available to a library. It is attached. 

In this test, DefineScopeTest.ino includes Defines.h and a library class called NewClass.h. the sketch creates an instance of NewClass which does not include Defines.h (the line to include it is commented out). Defines.h contains only "#define FOO true". The NewClass constructor displays the value of FOO.

This seems to prove that defines included in the .ino file are accessible to library files. 

I have literally thousands of lines of code that support this assertion, so I am puzzled by your statement that "An Arduino library has no access to project code. It's a basic rule."

Bob

  

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: Strange Compiler Behaviors
Reply #10 - Jul 26th, 2018 at 7:02pm
 
Yes it is confusing but correct.

You have code in a .h file not a .cpp. You will see in the verbose output that header files are not compiled, .cp;.cpp and .s files are compiled.

If you add a cpp to your library then it won't compile with the code your would normally put in the .cpp

One little tip, I realize this was just a test, is that library resolution is better if the library contains a header file with the same name as the containing folder. . For example \DefineScopeTestClass\DefineScopeTestClass.h.





  
Back to top
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #11 - Jul 26th, 2018 at 9:55pm
 
Tim,

I have spent all day pointing on this and am deeply puzzled by what I see. I have included three screen shots and the compiler output. Here's the summary. Img1 shows that the compiler is including the Robot.h file correctly for this sketch. Img2 shows that it is also including the BJBufferManager and BJRF24SendReceive headers properly. Img3 highlights (but not so obviously) the problem. There is an error message being generated that says, the WIFI_CE_PIN and WIFI_CSN_PIN "was not declared in this scope." But if I hold the mouse over this code, the definition pops up correctly, so the compiler DOES know about them but is somehow getting confused. 

I am so baffled by this that I did a complete hardware memory scan just to see if it was some sort of hardware problem. 

Any clarity you can shed on this mess, gratefully appreciated.
  

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: Strange Compiler Behaviors
Reply #12 - Jul 26th, 2018 at 10:48pm
 
Hi Bob,

The visual studio intellisense and the visual micro compiler are two separate things. Intellisense should be considered as help/tips only and in this case, as explained earlier in this post, visual studio does not know that arduino libraries and core are compiled as separate items. You could open one ide for libs and one for your project but that's a faff so the downside of the simplicity of vs shared projects is that vs thinks libraries to be part of the project.

It would help to know you have read my previous post about sharing defines from the project inside libraries and how to #include and set the -I compiler switch before I look at your files.

Thanks
  
Back to top
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #13 - Jul 26th, 2018 at 11:12pm
 
Tim,

I have read every line of each of your posts several times, but that doesn't assure either of us that I understand what I am reading. 

You make several references to intellisense, but with I compiling with indellisense, or at least I don't think I am.

I am religious about using the -I switch. In the img1, you should be able to see that Robot.h seems to be being included properly. are you saying that when I hover over the references to its values (see IMG3), that is intellisense lying to me? I guess what I am asking is that if the file with the definitions is included, shouldn't the definitions in that file be visible?

Thanks again for all your help.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Strange Compiler Behaviors
Reply #14 - Jul 27th, 2018 at 12:20am
 
I see. Yes it's intellisense "lying" to you unless you have added the project folder as a -I compiler include. It's a 90% solution if you want to edit libraries in the same solution as your project without giving access to -I{sketch_path}. Of course you do not have to do that but you have to weigh accuracy with convenience.

Hovering a variable is intellisense, red squiggles are intellisense, the errors list with intellisense selected is intellisense, right click f12 goto definition is intellisense, view code snippets and everything in the editor is intellisense.

When you build the "Micro Build" output window is the real compile. It does also pump errors and warnings into errors list but, as I said, it is hard to read. The Micro Output window after a verbose build should show similar information to the arduino ide when it builds in verbose mode. So a real arduino build should always be something clear.

« Last Edit: Jul 27th, 2018 at 4:47pm by Tim@Visual Micro »  
Back to top
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #15 - Jul 27th, 2018 at 3:27pm
 
Tim,

Thanks again for the help. What I still don't understand is why can Intellisese see the value of defines that aren't visible to the compiler? They have been read in and captured somewhere, but the compiler seems oblivious to this. How is that?

Bob
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Strange Compiler Behaviors
Reply #16 - Jul 27th, 2018 at 4:45pm
 
Have you set the -I compiler include? if so what is it set to and what is the name of the property you have used? Does the include path show in the compiler output when compiling your lib code?

If you lib code cached from a previous compile? Did you click Build>Clean to ensure the libs are rebuilt? The compiler output clearly shows when building from cache. If you have not changed lib source but have added the project -I include then this could be the issue.

Have you added the #include in the lib code for the defines.h that exists in the project folder?
  
Back to top
WWW  
IP Logged
 
Bob Jones
Full Member
***
Offline


Posts: 210
Location: Bellingham, WA
Joined: Dec 4th, 2015
Re: Strange Compiler Behaviors
Reply #17 - Jul 27th, 2018 at 6:39pm
 
Tim,

The Extra flags property is set to -I"{sketch_path}" and I have an include statement in every lib header that references the defines in question.

I do Build->Clean and I also delete the contents of the temp folders and even the .vs and__vm folders.

I will repeat this exercise the next time I run these tests (later today) and again, thanks for your great support.

Bob
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12071
Location: United Kingdom
Joined: Apr 10th, 2010
Re: How to reference #defines created in a project from library code - SOLVED
Reply #18 - Jul 27th, 2018 at 7:21pm
 
Just do the build clean.

There is no need to run anymore tests. I have described how both visual studio and arduino work.

If you want to access defines created in project code from cpp library code then you should add the -I{sketch_path} compiler extraflag.

In the library code you can #include <header_name.h>

You correctly pointed out that non-compiled files such as .h files that are referenced via project code will use the project defines



« Last Edit: Jul 27th, 2018 at 7:23pm by Tim@Visual Micro »  
Back to top
WWW  
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint