The selection of subfolders included to the path is not consistent with the Arduino IDE

[danielfmo]

Hello,

libraries cannot use #define set in the .ino

I've just created a useless library that have some #ifndef and #if !defined statements where if a variable is not defined I raise an error. The variables are defined in the .ino file like bellow:

#define MY_CONDITION1
#define MY_CONDITION2

#include "UselessLib.h"

void setup()
{}
void loop()
{}

Code of the library (UselessLib.h):

#ifndef uselesslib_h
#define uselesslib_h

#define MY_LOCAL_CONDITION
#if !defined(MY_LOCAL_CONDITION)
    #error MY_LOCAL_CONDITION was not defined using #if !defined.
#endif

#ifndef MY_CONDITION1
    #error MY_CONDITION1 was not defined using #ifndef.
#endif

#if !defined(MY_CONDITION2)
    #error MY_CONDITION2 was not defined using #if !defined.
#endif

#endif /*uselesslib_h*/

This project works with the ArduinoIDE.

Thank you all in advance

UselessLib.zip

[jantje]

This is a known limitation of the .ino format. It does work with .cpp files. You can add defines at the project level in project properties->arduino->compile options using the format -D[define]

[danielfmo]

Hi @jantje,

Thank you for the quick reply.

That is true in the given example, indeed if I create a .cpp project with the same code as above I'm able to successfully compile it.

Though the issue is still present between the same library.

For example, if in the Project.cpp I have:

#define MY_CONDITION1
#include "UselessLib.h"

Then in UselessLib.h I have:

#ifndef MY_CONDITION1
    #error MY_CONDITION1 was not defined using #ifndef.
#endif

#define MY_CONDITION2
#include "drivers/UselessDriver/UselessDriver.h"

And finally in the UselessDriver.h I have:

#ifndef MY_CONDITION2
    #error MY_CONDITION2 was not defined using #ifndef.
#endif

MY_CONDITION1 is properly inherited , but not MY_CONDITION2

[jantje]

MY_CONDITION1 is properly inherited , but not MY_CONDITION2

Are you talking about gui output or compile output? The compile should be fine with .cpp. There simply is no reason to doubth that. I would expect the gui to show bugs. Again I think that is "expected behaviour cause by a inferior way of working" As I said define the variables in the project properties. That is what you should do. All other solutions have serious drawbacks.

[danielfmo]

I get compilation errors, the #error is outputted because MY_CONDITION2 is not defined.

I use a library (more like a framework) that is based in this concept of using #ifndef blocks to decide which libs to include. So, defining the variables at the project properties would empli re-implementing this framework in a static way.

Thank you

[jantje]

I don't see how Slober can cause this. So unless you can prove the problem is with Sloeber this issue is cause by your c/cpp skills.

[jantje]

Because of a sponsor at patron I looked at this again and it works all fine here.

So, defining the variables at the project properties would empli re-implementing this framework in a static way.

I really do not understand how you come to that conclusion.

[danielfmo]

Hello jantje,

I'm sorry, I didn't expressed myself as I expected in that sentence. What I was trying to say is that defining the variables at the project level implies that I know which variables are defined and their values before compiling the project, but I don't. In fact that is what the library that I'm trying to use does.

The library in question the MySensors (https://github.com/mysensors/MySensors/tree/master) and I'm not able to compile any of it's examples.

I'm able to compile this library in VisualStudio+VisualMicro and with PlatformIO.

Thank you for your time

[jantje]

A problem with your library and Sloeber is that "core" and "drivers" folders are on the build path. I'll look for a better folder exclusion regular expression.

For the define problem simply defining at the project level is working as I expected.

What I was trying to say is that defining the variables at the project level implies that I know which variables are defined and their values before compiling the project, but I don't. In fact that is what the library that I'm trying to use does.

Project in eclipse = sketch For a particular sketch you should know the defines that need to be made. For instance I added the following to airquality.ino and (together with removing the folders from the build path) it works fine.

#ifdef __IN_ECLIPSE__
#ifndef MY_RADIO_NRF24
#error add -DMY_RADIO_NRF24 to the project properties. To do so right click the project in the project explorer select properties->arduino->compile options
//and add it to the "Append to C and C++ field
#endif
#else
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
#endif

[jantje]

As to the library specification only the root and src should be added. I have however a couple of libraries using utility as well.

[Stefke01]

Hello Jantje, Just verified and indeed things seems ok now (whil test it with actual live nodes) So for me this is an accepted Solution when using MYsensors 2.0

1. Add RF type to Project Compiler C/CPP options in Sloeber _-DMY_RADIO_NRF24 or -DMY_RADIO_RFM69
2. Exclude from Build in (Right Click "Resource Configuration" ) in "Libraries" folder (Lib) Mysensors>> Core && drivers dir's

Thnx for the quick response.

[jantje]

Eclipse CDT does not support negatives for exclusion. So I added 3 more exclusion filters.

[jantje]

This fix should be in the nightly build tomorrow.

[Stefke01]

Hello Jantje, I saw the adding of the RegEx. i don't want to test this on my "regular" system but i can test it this week on another system (if it is stil apply) And give you feedback ASAP. Also a warm call for more people to test drive this (and document their steps) with various projects/libraries and even platforms should help a lot. For example sometimes i see that a .ino project (sketch) behaves different vs a .cpp this in respect to #define DEBUG statements (change ignored)in the sketch but i cannot reproduce it consistently. (reproduce behaviour on another computer) sorry about that. Using a *.cpp extension should be the standard and then there will be less problems anyway ;-(

-I assume that defined symbols for the preprocessor (-D) option still apply after the patch? Regards Stefan.

[jantje]

This fix is only to exclude the extra folders in the library. It will only work on newly created projects. As to testing: You can install 2 eclipse versions next to each other on the same machine. As to .ino versus .cpp. I advice to use .cpp. I consider support for .ino files in sloeber "mainly for creating projects based on examples and example development when doing library development". I advice to use .cpp when doing project development. After all in a project nearly 90% of the code will be in .cpp files anyway (core,libraries).

[Stefke01]

Hello Jantje, At last i managed to do a test.. When i do a include with the library manager only a few folders get included on my computer for being honest i don't remember that i didn't copy the Mysensor library directly in sloeber V1 (sloeber2 is the one with the patch ) On my other computer things just worked without exluding the core/driver/... libs, so i think i messed it up on my system. After this succesfull build on the (virgin system ) i did a complete setup off sloeberV2 and now everything works as expected.. I also did a upload off the build and this was also working

What is the best procedure to upgrade to this version ? (without re-importing all projects from previous version ?) is it possible to copy just from one Workspace to another? Regards, Stefan.

[jantje]

Thanks for confirming it works now :-) There are many things that can be upgraded. Assuming you mean upgrading sloeber. http://eclipse.baeyens.it/how_to.shtml#/n

[cravecode]

Sorry to hijack this issue. I'm trying to get the MySensors library to work in the 2016-09-06 nightly build (Mac OS). I'm getting several compile errors in the RF24.cpp resource. They are: not defined in this scope errors. The items referenced in the errors are defined in other files. The root of the issue seems to be caused by the variables defined in the MyConfig.h. It appears that the MyConfig.h is not being involved in the build process. How is this handled differently in the Arduino IDE vs. Sloeber?

@Stefke01, were you able to successfully build a sensor node?

[cravecode]

For anyone else having issues. I believe it was an issue with how I had Sloeber configured to use libraries. I started over by removed all values under Preferences > Arduino > Private Library path, then added the path to my Arduino IDE's library. I removed, then added back the needed libraries to my project under Arduino > Add a library to the selected project. It now works as expected.

[Stefke01]

Hello Cravecode, Congratulations you build Mysensors with the best IDE available at the moment! (imho) As long you use the nightly build it should work. Beware however that Jantje is re-organizing some things on the Nightly (But i think 09/06 should be fine.) Here are some hints: Also see the suggestion of 17/aug (the compiler option) 1)The build proces is a complex thing however test build one off the sketches included in Mysensors before brew yourself something is also a must. 2)When you setup a project and compile first time it is possible not everything is in the build?? (maybe it is me.....) I test this to see .Text in the build vary in size (MY_DEBUG / no debug) 3)Close the IDE and restart solves this most off the time. 4)Avoid using the INO extension and use cpp! --However this has (again by my setting) a side effect: -that you need to prototype the functions before calling it in code (which is normal C/C++ behaviour). 5)Watch out before compiling & uploading you selected the RIGHT ino /cpp file (otherwise you compile/ upload another project) This is due the fact that the editor and compilation is not in sync!

Enjoy autocompletion, file historic, project explorer (til arduino core for the undaunted), etc

[jantje]

@Stefke01 thanks for the nice words. The feedback you give here is very interesting to me as it allows me to see how people use things compared to how it is intended to be used. So here some feedback on how it is supposed to be used.

1)The build proces is a complex thing however test build one off the sketches included in Mysensors before brew yourself something is also a must.

100% agree. It is not even Sloeber related. If something fails... try the examples. Start with the easiest one.

2)When you setup a project and compile first time it is possible not everything is in the build?? (maybe it is me.....) I test this to see .Text in the build vary in size (MY_DEBUG / no debug)

I'm not 100% sure what you are referring to. I assume you are referring to the automatic include that needs some time to find the libraries. I talk about this in the new and noteworthy part 2 https://www.youtube.com/watch?v=x_JKcvqpxq8&index=2&list=PLCSjf7QmP3TDPSjT_5UIp0DHXzKdhIQsF If a library is not found editing and saving the file that refers to the header of the library can fix the issue. Also a project->indexer->rebuild can fix it. Alternatively adding the library to the project using the Arduino menu will always work. If you can't find the library in the "add library to project" than you need to add the library to your environment using windows->preferences->arduino (there are 2 ways here)

3)Close the IDE and restart solves this most off the time.

I never needed to do this. but I do select project->indexer->rebuild index.

4)Avoid using the INO extension and use cpp!

I would say: be aware that .ino files are converted to .cpp files. This post explains the build process (of which the .ino to .cpp compiation is part) https://www.patreon.com/posts/there-are-bugs-5507246 Note if you do not see the .ino.cpp file that probably means .* files are filtered from the view (this is by default). To remove the filter: in the project explorere click the triangle in the top right corner and select filters.... Make sure there is no check-mark before ".* resources"

5)Watch out before compiling & uploading you selected the RIGHT ino /cpp file (otherwise you compile/ upload another project) This is due the fact that the editor and compilation is not in sync!

The upload is based on the selected project in the project explorer. No the selected file. In the project explorer there is a "link with editor" button. If that one is activated the upload "should be" linked to the editor. I say "should be" because: 1) I don' really like the code to find the selected project. (It is the best I could come up with) 2) Library source files can be linked and linked and linked... so it is "normal" the "link with editor" may end up in a wrong project. 3) the same linking problem counts for core files.