Private libraries should ignore files starrting with a . when deciding wether a folder is a library or not

[jrobert-gh]

With this update, '#include <local.h>' draws a "Unresolved inclusion: <local.h>" in the edit window and "fatal error: local.h: no such file or directory." in the CDT Build Console. The path to my libraries folder is correct; the libraries folder contains a 'local' folder which contains the 'local.h' file.

This was working with Sloeber 4.0. After upgrading to 4.0 -> 4.2, I created and built the Blink example from within Sloeber; it compiled correctly. Then I added "#include <local.h>" and got those error messages. In the sketch, I changed "#include <local.h>" to "#include <SimpleTimer.h>" (and confirmed that my library contained SimpleTimer.h, also
properly structured) and it got the same two errors.

Sloeber 4.2
MacOS 10.13.2
Arduino IDE app 1.6.12

jrobert-gh
(patron)

[wimjongman]

Can you throw away the arduinoPlugin directory and restart? This allows Sloeber to freshly fetch the arduinoPlugin code.

[jrobert-gh]

My update was done "clean":

• Removed the entire Sloeber 4.0 app with App Cleaner.
• Removed everything but source code from my workspace and its project- and library-folders (i.e. removed all dot-files, all folders made by Sloeber).
• Downloaded and installed Sloeber, V4.2_mac64.2017-11-20_02-16-52.tar.gz

I think that should refresh everything Sloeber related - ?

[jantje]

The path to my libraries folder is correct; the libraries folder contains a 'local' folder which contains the 'local.h' file.

Assuming that this means: In windows->preferences->arduino there is a reference to a folder that contains a subfolder local that contains a file named local.h (mind the casing)

I see the following problem:
As to your information there should be a libraries/local/local.h in your project.
As the provided image there is no libraries folder in the root of your project. This is why the build fails.

First thing to do is trying to add the library via Arduino->"add a library to the selected project".
If you can find the "local" library (again mind the casing) you can:

1. add it to the project and the build should be fine.
2. assume there was a indexer problem
3. assume there is a bug in Sloeber
4. check the windows->preferences->arduino->"automatically import libraries based on includes?" option

If you can't find the local library there is something wrong in your (understanding of) the private libraries.
Basically Sloeber can not find your library and can not add it to the project.

As an independent open source project we value your submission, but we ask for support, either by helping us out coding (yeah, we do understand it does require time) or a Patreon contribution (starting from as low as 1$ a month): this allows us to support people who support us back!
As a supporter you can drag our attention and prioritize your submission...
please become a supporter!
https://www.patreon.com/jantje

[jrobert-gh]

Jantje, You and I have corresponded about the library structure for Sloeber in the past. My library structure has been working with prior revs of Sloeber. The workspace has a 'libraries' folder in it; which has a 'local' folder in it; which has 'local.h' in that:

The entire project (minus the #include) was generated by Sloeber. As I've stated, I started with a brand new installation of the Sloeber app and a Sloeber-clean workspace - every project. I generated a new Blink sample-project with the newly installed Sloeber. It compiled. I added the #include and the compilation broke.

I will try your suggestion to "add a library to the selected project", and thank you. But if that is a requirement, it is a new one. Until now (4.2), I had only to #include the .h file (given that my library was structured as you described - it was, and still is) and my code would compile and link with that library.

[ off topic: ]

please become a supporter!

I was a Patreon-patron of yours until they f'd up the payment structure and I left them. At that time, you and I arranged that I could support you independently, which I did on Dec 28; that PP transaction code ends with "162X".

Recognizing patrons when we file issue reports has come up in the past. In the first posting to this issue, I stated in my sig that I am a supporter. Is there another way you'd prefer patrons to identify ourselves as such?

jrobert-gh, on github,
JRobert, most other places

[jantje]

@jrobert-gh
Sorry I didn't recognize you. I'm just arrived back home from 2 busy days and I wanted to help out quickly.

Sloeber 4.2 works with the folder structure as you provided. The only thing that changed in this area is in pre 4.2 you had to point to the parent of the library folder (in your case "ArduinoWksp/libraries") from 4.2 you can also point to libraries directly (like "ArduinoWksp/libraries/local").

But I think we are misunderstanding each other. What I'm proposing is steps to find the root cause. Not a solution.
"add a library to the selected project" full-fills the basic actions that need to be done when you do a include. By default sloeber will do this action based on "missing includes found by the indexer" (and in case of creating project based on library examples)
For one reason or another this "add a library to the selected project" is not auto triggered in your workspace. I know so because there is no libraries folder in your project.
I ran some tests here before I answered this issue and I found that there are no loggings in the error log when a include is not found. (there are messages when a include is found; I guess I removed the failing message when I implemented the auto install functionality)
That is why I proposed to go for the "add a library to the selected project" functionality.
The outcome of this action will tell us whether Sloeber "can find the library" or something else like "the indexer is not(?) missing the include" or "the auto include functionality is turned off" or "some wierd bug" or ... .
So please report back on the result of the "add a library to the selected project" action.

PS I have been in this situation quite a few times. In most cases the problem was user error like:

1. case sensitivity (so include not properly spelled)
2. private libraries not pointing to the right spot (again case sensitivity)
   In other cases the indexer didn't see the file as unresolved. This has to do with bad indexer settings (therefore the warning you get at startup until it is set properly) or corrupted indexer database.
   You can check by right clicking the project ->index->search for unresolved includes

[jrobert-gh]

in pre 4.2 you had to point to the parent of the library folder (in your case "ArduinoWksp/libraries")

This is how I have referred Sloeber to my libraries, and still do. It has been working properly. Spelling & casing are all still correct.

I tried the various options you suggested:

• "add a library to the selected project" - same failure; the dialog named ArduinoWksp/libraries but didn't mention anything contained in it. I selected ArduinoWksp/libraries, but the compile still failed.
• "Index | Re-resolve unresolved includes" - same failure; Compile got "No such file or directory" again.
• "Index | Search for unresolved includes" - merely identified the .h file I already knew hadn't been found. Curiously, once I did this, the project right-click menu-item "Build Project" got grayed out. Using the Verify button instead, the compiler got the same failure.
• "automatically import libraries based on includes?" - same failure.

BTW: "Automatically import libraries based on includes" was/is already checked. That is the behavior I want and used to have.

[jantje]

"add a library to the selected project" - same failure; the dialog named ArduinoWksp/libraries but didn't mention anything contained in it. I selected ArduinoWksp/libraries, but the compile still failed.

It is not clear to me what you mean with this.
Was the local library listed?

[jrobert-gh]

No. This is the dialog that "add a library to the selected project" presents:

And this is my libraries structure:

[jantje]

I see the problem :-)
The Add library to project does not find the local library.
As stated In 4.2 you can add the library itself to the private paths.
Where before V4.2 Libraries were assumed to be the chlidren of the parent this logic could no longer be used in V4.2.
When I implemented is a "does the folder contain code"? logic.
Basically is there a *.c *.h ¨.cpp file in the folder.
In the new image you see there is a mcu_types.h in the libraries folder which makes V4.2 think your pre V4.2 private hardware (children folders are libraries) is a V4.2 type private hardware library.
Solution remove all source code from the libraries folder.

[jrobert-gh]

Thank you, but I'm afraid that didn't fix it here. I removed everything from ArduinoWkspc/libraries that isn't a library- folder. There are now only folders in 'libraries'. Each contains at least a same-named .h file. Then I deleted my Blink sample-project (files deleted too), built a complete new one, and compiled it. It compiled OK.Then I added the line "#include <local.h>". The compile then failed with: "../sloeber.ino.cpp:8:19: fatal error: local.h: No such file or directory". 'libraries/local' contains: local.h localWiFi.h localutils.cpp localutils.h

On Mon, Jan 8, 2018, at 2:18 PM, jantje wrote: I see the problem :-) The Add library to project does not find the local library. As stated In 4.2 you can add the library itself to the private paths.> Where before V4.2 Libraries were assumed to be the chlidren of the parent this logic could no longer be used in V4.2.> When I implemented is a "does the folder contain code"? logic. Basically is there a *.c *.h ¨.cpp file in the folder. In the new image you see there is a mcu_types.h in the libraries folder which makes V4.2 think your pre V4.2 private hardware (children folders are libraries) is a V4.2 type private hardware library.> Solution remove all source code from the libraries folder. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[1], or mute the thread[2].>

Links: 1. #895 (comment) 2. https://github.com/notifications/unsubscribe-auth/ARfMdZ-8jawHvx1MenpDCEt0QlvgD72-ks5tImoggaJpZM4RVaOM

[jantje]

Sloeber does caching on these libraries (for performance reasons) so you also need to restart sloeber after the file removal.
If it is still not working please check whether you see the local library in arduino->add library to project

[jrobert-gh]

No, even after a restart, "add library to project" shows the same "Import Arduino Libraries" dialog as in my screenshot about 3 posts back.

[jantje]

Can I get a copy of that libraries folder for testing?

[jrobert-gh]

Sure - It's on its way....

On Tue, Jan 9, 2018, at 4:41 PM, jantje wrote: Can I get a copy of that libraries folder for testing? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[1], or mute the thread[2].>

Links: 1. #895 (comment) 2. https://github.com/notifications/unsubscribe-auth/ARfMdYnUMw0_IyhrOlghPuY_2sorNxniks5tI90QgaJpZM4RVaOM