I am new to software and just getting started on Particle using Relay Shield. I used the Web IDE successfully, now moving to the Particle Workbench on the desktop (need the serial debug). When I create a new project, copy the code from the example code, it’s giving a compile error.
build.mk:65: *** “No sources found in c:/Sunder/projects/Particle IO/junk2/Trial/”. Stop.
make[2]: *** […/…/…/build/recurse.mk:12: user] Error 2
make[1]: *** […/build/recurse.mk:12: modules/photon/user-part] Error 2
make: *** [C:\Users\sunder.particle\toolchains\buildscripts\1.5.0\Makefile:42: compile-user] Error 2
The terminal process terminated with exit code: 2
Can someone help with this? or point me to a step-by-step tutorial to compile, run and debug with the serial port on the Desktop workbench. Any help appreciated
these and other resources are available within Workbench via the Particle: Get Help command - from VSCode’s main menu, click “View > Command Palette” and then start typing “Particle” - or from the “Welcome” screen that is shown when you click the Particle logo in the main Activity Bar on the left.
I’m getting the same error compiling locally so I landed on this conversation.
My sources are in the /src folder. However, I have a library that uses sub folders so I have /src/util/ folder too. Must src be flat with no sub folders? (And I have a readme.md and changelog.md in the base folder)
I have not yet tested moving the files out of the sub folder, not knowing if I’ll end up with new problems or not.
So for anyone else coming across this thread…not all of these things may be a problem, but follow along and it may solve your problem too.
When trying to create a new project it wouldn’t due to a space in the folder name. So it may not build if your current project is in a folder like /users/me/Visual Code/projects/Test1/
So I moved my folder to c:\test1\ but it wouldn’t build. Interestingly, a .cpp file appeared that was never before in my project folders.
Then I moved supporting library files from my src/utils/ sub folder into the main src folder, and updated dependencies. Still would not build.
Deleted the now empty src/utils/ sub folder.
Finally it build! Yay. And took maybe 15 minutes. I’m not sure the local compile will get much use taking that long and not sure if that is normal or if there is a way to speed it up.
Was it a .cpp file with the same name as your .ino?
If so, that's to be expected. It is the output of the Partice pre-processor converting the .ino (which the compiler wouldn't touch) into something the compiler likes to work with.
I can confirm that Workbench has no issues with subfolders under ./src as long there are no conflicting files in it, but (real *) libraries should rather go into a subfolder./lib/<libName>
Can you provide some tree diagram of a non-working project for us to test?
*) real libraries adhering to the library standard structure with a library.properties file and all.
Thanks @ScruffR for taking a look. This morning I tried to retrace the steps.
Yes, the .cpp file is the same name as the .ino. Part of the point is that the .cpp file does not build when your project is in a folder with a space (in my case meaning a folder higher up in the tree, e.g. “/users/me/Visual Code/projects”). So if there is no .cpp file that is the first hint of the problem.
This morning it did compile with the src/utils/ sub folder, when I exercised a lot more patience and paying attention. When the project folder (with the space removed) is opened it takes a really long time for it to go through its process (keeping an eye on the terminal until it is finally done).
Then compiling locally, the terminal is stuck at “/makefile” for almost 9 minutes before finally there is some action and part 1 is produced. It takes nearly 20 minutes before finally part 3 with the user firmware is completed.
I think my prior perception of failure is either I interrupted the process or assumed it to be completed when it was still stuck on “/makefile”.
My libraries are actually in the /src folder. I’ve not created a libraries.properties file so I guess they are not *real.
PS: Running local compile a 2nd time (no code changes), it only takes 45 seconds to get to part 1, 1:30 to part 2 and finishes part 3 after 2:10.
Yup, that's expected. A full build with all modules for the first time takes ages on Windows, but as long the sources are unaltered (and you don't switch platform) previously compiled modules can be reused.
You can also add support to different directories by customize the file tree. The default configuration to avoid mistakes if you don’t have much experience with build environments is to only look at root/lib and root/src. In fact, the default make file has a weak definition to the make file in use, allowing you to point to a new one:
USER_MAKEFILE ?= build.mk
and if you want to follow different standard to organize your code, like root_folder/app/src; root_folder/app/include; root_folder/lib1/src; root_folder/lib1/include you can customize your make file with the following entries: