Issues compiling locally and on the cloud

[Theja]

Hello,

We have been actively developing our systems using the P1, initially with DeviceOS v2.0.0 until last week, and recently switched to DeviceOS v3.3.1. Unfortunately, today we encountered a sudden problem where we were unable to compile our code. Numerous issues arose unexpectedly, affecting both myself and my colleague.

Specifically, we experienced difficulties with cloud and local compiling throughout the day. All the errors we encountered were related to include errors, such as "No such file or directory." Importantly, we have not made any modifications to the project structure, which has remained unchanged for over a year.

To provide some context, here is a breakdown of our project folder structure:

• ${workspaceFolder}/src/: Contains all CPP files.
• ${workspaceFolder}/lib/: Contains all libraries.
• ${workspaceFolder}/include/: Contains all header files.

We have thoroughly checked and ensured that our particle.ignore and particle.include files are properly configured. These files have been in place for quite some time, and we have not encountered any issues with them until today.

Any insights or suggestions would be greatly appreciated.

Edit: (Update)
In an attempt to resolve the issue, we moved all our headers and libraries to the ${workspaceFolder}/src directory. Surprisingly, after this change, both cloud and local compilation worked without errors. However, it is important to note that the project structure hasn't changed for a long time now. We are curious as to why this issue is occurring now, seemingly out of the blue.

[rickkas7]

I'm surprised /include in the project directory ever worked. That never been a location that's searched for header files for local or cloud compiles.

[Theja]

Interesting. Would that have been the case even if we added the include/ directory in particle.include?

[rickkas7]

The particle.include file was only added this week, and it's only used for cloud compiles.

It's a mystery how it worked before! It would have worked if you had a src/build.mk that changed the compiler include search path, but I presume you didn't have one before.

[Theja]

Wow, that's truly strange! It's hard to comprehend why this issue is occurring now, especially considering that we have been using the particle.include file for years. I personally recall it being in place since I joined the company over three years ago. It has been an integral part of our development workflow all this time.

You are correct. We do not have a src/build.mk file in our project structure.

The sudden appearance of this problem has caught us off guard, given that our project structure has remained consistent for an extended period. We are genuinely intrigued by the cause behind this unexpected behavior.

[Theja]

@rickkas7 what do you suggest we do in this situation? Any recommendations or insights would be greatly appreciated.

[Theja]

Update:

After studying the particle project structure, we dedicated a couple of days to reformatting our project. Here's an overview of the various structures we experimented with:

With perseverance, we eventually achieved successful compilation both locally and on the cloud by implementing the extended structure. Here's the updated structure we adopted:

.
├── Library1/
│   ├── src/
│   │   ├── <srouce>.cpp
│   │   └── <header>.h
│   ├── library.properties
│   ├── docs
│   └── examples/
│       └── usage/
│           └── test.cpp
├── Library2/
│   ├── src/
│   │   ├── <srouce>.cpp
│   │   └── <header>.h
│   ├── library.properties
│   ├── docs
│   └── examples/
│       └── usage/
│           └── test.cpp
├── src/
│   ├── <helper1>/
│   │   ├── <helper_header1>.h
│   │   └── <helper_source1>.cpp
│   ├── <helper2>/
│   │   ├── <helper_header2>.h
│   │   └── <helper_source2>.cpp
│   ├── main.cpp
└── project.properties

The reformatting process was time-consuming due to the presence of approximately 180 files.

We hope that sharing this information will be beneficial to others!