I am having an issue attempting to access a header file in a subdirectory of a library from within that library. I've read through a lot of posts regarding issues with subdirs in various locations for both sketches and libraries. I have not found one that addresses my specific issue. Nor have I found an example that can provide me a good illustration.
I have a header file (opener_api.h) that #includes an internal header file (ciptypes.h) which resides in a subdirectory called cip. The folder structure looks like the following:
When the compiler processes opener_api.h it tells me ciptypes.h cannot be found. I have tried modifying the #include to use all of the following without success:
The error is:
opener_api.h:13:22: error: ciptypes.h: No such file or directory
#include "ciptypes.h"
^
The library I am attempting to port (OpENer) is written in C so i have wrapped my initial #include in an extern "C".
I am using IDE 1.8.8 and compiling for a MKRZERO.
Try compiling the code with the other incorrect #include directives removed.
If that doesn't work then I agree with PaulS that it would be helpful if you attached the library to a reply here as a .zip file so that we can see the structure in real life and try it out. If you click "Reply", you will see an "Attachments and other options" link at the bottom of the reply window that will allow you to attach files.
PaulS:
Let me think. You are asking us about code we can't see. Yep, I can think of something. I'll be you can, too.
That little underlined part of my post is called a URL. It's amazing, if you click on it it takes you to a different webpage. You may even find something relevant to my post. I figured out how it works. I bet you can too.
Try compiling the code with the other incorrect #include directives removed.
If that doesn't work then I agree with PaulS that it would be helpful if you attached the library to a reply here as a .zip file so that we can see the structure in real life and try it out. If you click "Reply", you will see an "Attachments and other options" link at the bottom of the reply window that will allow you to attach files.
I did include a link to the github repo in my original post. I posted all the relevant information I thought was useful to my error. Since I have just begun attempting to create this port I did not want to splash tons of other useless info. If you still think its worthwhile to upload the file I will do so.
csobsidian:
If you still think its worthwhile to upload the file I will do so.
Did you try what I asked you to do? If it solved the issue then no, it's not worthwhile.
If it didn't solve the issue then I do think it's worthwhile and this is why: You said:
csobsidian:
The library I am attempting to port (OpENer) is written in C so i have wrapped my initial #include in an extern "C".
This leads me to think that you have modified the library at that link. We need to look at the code you're actually compiling, not the code you based the code you're compiling off of.
This leads me to think that you have modified the library at that link. We need to look at the code you're actually compiling, not the code you based the code you're compiling off of.
THAT was my point. Went right over OP's head. Or some part of his/her anatomy...
pert:
Did you try what I asked you to do? If it solved the issue then no, it's not worthwhile.
If it didn't solve the issue then I do think it's worthwhile and this is why: You said:This leads me to think that you have modified the library at that link. We need to look at the code you're actually compiling, not the code you based the code you're compiling off of.
Other than putting the source into the correct directory in my arduino libraries folder, I have made no other changes to the library than to attempt to modify the offending include statement per my original post. I do appreciate your helpfulness. To be clear, the first thing my code in my sketch does is call the #include opener_api.h. The compiler exits at the first header in opener_api.h that it can't find which is ciptypes.h in a subdir of the library. I built a test library that compiles just fine so I have attached the library I am trying to port, as is. Maybe there is something extraneous in there causing the compiler to crap out.
@PaulS Thank you for reminding me that the stereotype of smary, snarky, holier-than-thou internet troll is alive and well. You have been super helpful as I try to navigate this community for the first time. It's nice to know this place is as welcoming and helpful as I have been told. You are a true asset here.
MorganS:
Don't believe. Test. What happened when you tried it?
The test library I mentioned in post #9 uses both forward and back slashes without issue. I posted the library that does not successfully compile for me (also post #9) because I'm leaning toward this being a possible issue with my IDE. My IDE will not compile the OpENer lib past the first call to #include "ciptypes.h" contained in opener_api.h, no matter what syntax I use.
csobsidian:
The compiler exits at the first header in opener_api.h that it can't find which is ciptypes.h in a subdir of the library.
I already explained what you need to do back at reply #3:
pert:
The correct syntax is:
#include "cip/ciptypes.h"
You need to update all the #include directives to specify the relative paths of the source files. There are multiple #include directives you need to modify in this way but if you do that with all of them then the "No such file or directory" errors will be resolved.
csobsidian:
The test library I mentioned in post #9 uses both forward and back slashes without issue.
Backslash path separators work only under Windows. They will not work when using other operating systems. Forward slashes work with every OS (including Windows). This is why you should always use forward slashes in #include directives.
pert:
I already explained what you need to do back at reply #3:You need to update all the #include directives to specify the relative paths of the source files. There are multiple #include directives you need to modify in this way but if you do that with all of them then the "No such file or directory" errors will be resolved.
Backslash path separators work only under Windows. They will not work when using other operating systems. Forward slashes work with every OS (including Windows). This is why you should always use forward slashes in #include directives.
Attempted with no success. I still get a no such file or directory error.
When you encounter an error you'll see a button on the right side of the orange bar "Copy error messages" (or the icon that looks like two pieces of paper in the Arduino Web Editor). Click that button. Paste the error in a message here using code tags. If the text exceeds the forum's 9000 character limit, save it to a text file and post it as an attachment. If you click the "Reply" button here, you will see an "Attachments and other settings" link.
pert:
When you encounter an error you'll see a button on the right side of the orange bar "Copy error messages" (or the icon that looks like two pieces of paper in the Arduino Web Editor). Click that button. Paste the error in a message here using code tags. If the text exceeds the forum's 9000 character limit, save it to a text file and post it as an attachment. If you click the "Reply" button here, you will see an "Attachments and other settings" link.
As requested:
Arduino: 1.8.8 (Windows 10), Board: "Arduino MKRZERO"
In file included from C:\Users\user\Documents\Arduino\enip\enip.ino:2:0:
C:\Users\user\Documents\Arduino\libraries\OpENer\src/opener_api.h:13:26: fatal error: cip/ciptypes.h: No such file or directory
#include "cip/ciptypes.h"
^
compilation terminated.
exit status 1
Error compiling for board Arduino MKRZERO.
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
csobsidian,
It is possible is that you are being burned by a very unfortunate decision that the Arduino team made some time ago.
This was the topic of some debate. I was not in favor of what was done.
The Arduino team decided to no longer build things in place or even use pointers to the actual original source code when doing builds, or even copy your full sketch or library tree to their temporary working/build area.
They now copy your code tree to temporary area and do the build from there. How this is done, and what all is copied has changed over the years and I'm not fully up to speed on the latest way it is done, but I do recall that not the full tree was copied over - at least there were some revisions of the IDE that didn't copy all the sub directories and which ones were copied has varied in different releases as the Arduino team changed things to deal with feedback they were getting about how this new build mechanism was breaking things in various previously working projects.
Also, from what I remember, libraries and sketches are handled differently, so it is possible that you can have different issues with each depending on what you are doing and your directory tree structure.
You can see if this is what is burning you by turning on full debugging in the IDE and looking at the paths to see where the code is being built. Then go down to where the code is being built and look around to see if the files you need were copied down there.
MorganS:
Don't believe. Test. What happened when you tried it?
slashes should always be used in paths for include files regardless of OS.
Backward slashes are a windows thing and while the compiler people eventually caved and supported using them in include file paths, they really shouldn't be used as it creates portability issues.