"No such file or directory" for .h files with Particle Dev and CLI

I have read other posts regarding this issue, but none that seemed to match my situation. I must be missing something.

I have a project that was compiling w/o errors using Particle Dev about a month ago, but now I can’t get it to compile. I originally got the dreaded “compiler timed out or encountered an error” error. Following rickkas7, I changed the main file from Stepper.ino to Stepper.cpp, added #include “Particle.h” to it, and removed the project.properties file. That resulted in the “No such file or directory” error.

My project directory structure looks like this:

And the first lines of Stepper.cpp look like this:

#include "Particle.h"
#include "ByteQue.h"
#include "CmdHandler.h"
#include "encoder.h"
#include "powerSTEP01.h"
#include "stepper.h"

const String strVersion("v1.0:");

When I compile in Particle Dev, I get

When I compile with CLI, I get:
Compiling code for photon

attempting to compile firmware
_[build output for ByteQue.cpp, which succeeds]_
_[build output for Stepper.cpp, which fails with:]_
**src/Stepper.cpp:18:24: fatal error: CmdHandler.h: No such file or directory**
 #include "CmdHandler.h"
**compilation terminated.**

But “CmdHandler.h” was included in the list of files sent to the compiler, and this directory structure was working before. Any guidance?

I recently had the same thing happen to me with an older folder that used to compile that now would not due to library structure changes on Particles end. This makes you change your code some to get it to compile successfully now.

If you throw all those files into the main Stepper folder it should compile just fine.


Or you could try adding this:

include "Particle.h"
include "ByteQue.h"
include "lib\CmdHandler\src\CmdHandler.h"
include "encoder.h"
include "powerSTEP01.h"
include "stepper.h"

You may need to do that to all of them if it starts complaining about other .h files not being avalialbe.

I see there are not library.properties files for ’ CmdHandler’ and ‘Encoder’.
I also don’t like the idea of removing project.properties from the project.

What was the reason for changing the way libraries were handled in the past vs the new 2.0 version?

Was it just for Arduino compatibility or are there other benefits?

It seems more complicated now and I’m not sure exactly why.

Is this a standard or accepted way of building or structuring libraries that is documented somewhere that we could read up on it more to get a better understanding of libraries 2.0?

I’ve looked at the structure of the 2.0 libraries but I still have no idea why the extra folders and files are needed when they were not in the past.

I can’t be the only one slightly confused about this? :confused:

One major benefit is the ability to have libraries and project require other libraries via the .properties files - even in a cascading manner.
The transition was a prerequisite for the library manager for CLI and Dev. Without it you always had to download the sources for libraries even if you didn’t intend to alter anything.
But Arduino compatibility is a big one too as it greatly reduces the porting effort for platform independent libraries.

The flip side of complexity is additional flexibility.

The starting point for that is now the Arduino docs

1 Like

Thanks for the quick responses. I won’t be able to work on this again until late tonight or early morning, but I will get back to you then. I thought the change to v2 libs was quite a while ago and I’ve compiled this app with this structure dozens of times.

As for removing the project.properties, that was part of rickkas7 recommendation to avoid the “Compiler timed out…” bug. I will put it back, but it only contains “name=Stepper”.

1 Like

I figured it out. I went back to an archived version from a month ago, and it compiled with no errors. A binary diff between that and the current version showed an extra 0x0D after:
#include "ByteQue.h"

I have no idea how it got there, but removing it solved the “No such file or directory” error on the next #include.

But it still wouldn’t compile. Now I was back to the original “Compiler timed out or encountered an error” error. So I installed the CLI, which succinctly pointed out the additions I had made to a header file produced a “variable defined multiple times” error. Since the h file was included in multiple cpp files, I had to change:
const char *LOG_FILE_BASE_NAME = "durbin";
static const char *LOG_FILE_BASE_NAME = "durbin";

and presto bingo, it now compiles in CLI and Particle Dev. My take-away is that continued use of Particle Dev requires CLI as a utility for reporting real errors! It seems that this is an ongoing issue and there must be some underlying implementation issues that prevent Dev from reporting compile and/or link errors.

Many thanks to all of you who took the time to help with this issue!


The correct way to deal with such an issue would be to guard against multiple inclusion via

#pragma once


#ifndef __HEADER_NAME__
#define __HEADER_NAME__
  implementation here
1 Like