Offline compiling, using APPDIR and src/inc folders


I’ve successfully set up an offline build environment using the ARM GNU Toolchain and Eclipse and am able to build software that is in the root of my APPDIR.

The reason I use APPDIR is to have the Particle system firmware and my application completely separated. In the future I want to have my own external libraries as well, but for now let’s focus on using APPDIR.

The issue I ran into is that I have to relative paths in my #include s, see my GitHub repo with a simple example I created.

In the main source file I have to use relative path to include add.h. Same goes for the other files.
In the root folder is also a Makefile from @rickkas7 's Eclipse debug example. To my understanding this makefile is needed here to build my applicatin which is located in the APPDIR. However in Particle’s firmware I see files in e.g. the wiring/src folder and in the wiring/inc folder.

Now, I don’t have a lot of experience with makefiles so at this point I don’t know what to do. The application works but only using these relative paths. I don’t mind using include paths from the root folder, but just not relative. I prefer to just use #include "add.h" if possible. Do I need to place makefiles in each of these folders?

I searched this forum and google but could not find anything for this particular case (external source code incl. libs using APPDIR). Really hope anybody can help!

Also planning to writing a guide about this when I got it all figured out to help other people!

1 Like

Hi @vidavidorra,

I also made a tool to assist with local offline development. It is called po-util, and it is available for Linux and macOS.

It is written in bash for cross compatibility, and is very powerful for building and managing Particle projects. It supports Libraries 2.0 as well.

In order to tackle the exact problem you described, it arranges a project in the following structure:

├ main.cpp
└ lib1/
  ├ lib1.cpp
  ├ lib1.h
  └ ...
├ firmware.bin
└ ...

It can even automatically add and remove headers when using libraries.

In this example, the headers in main.cpp would be:

#include "Lib1/Lib1.h"

Also, po-util operates by creating sybolic links to a central library repository. I have eliminated the need for modifying makefiles.

Po-util also has shortcuts for developing within Atom, or you can use it entirely via the command line.

@nrobinson2000 Thanks for your reply!

I’m however on a Windows machine, so don’t have the possibility (as far as I know) to symbolic link files. If I understand your application correctly, you basically have the folder structure you’ve described and would create a link in the root folder to lib1/lib1.h so than the main.cpp can just #include "lib1/lib1.h". Is this correct?

But lets say you also have this:

└ lib2/
  ├ lib2.cpp
  ├ lib2.h

In this case, creating a symbolic link in the root folder to lib2.h would enable the main.cpp to just include lib2/lib2.h but what if you want to include lib2.h from within lib1.h? Than you still would have to write the relative path (#include "../lib2/lib2.h"), right?

Does your application also work with Eclipse? I think it does since it basically works with the file system if I understand correctly?

On windows a symbolic link is a “shortcut”.

Thanks for taking the time to reply @nrobinson2000. I don’t really like using symlinks like that, and am pleased to say that I found a solution that works good for me.
I use a file in the root of my project (APPDIR), which basically defines the include paths. The other thing I found out is that .c files weren’t getting included, so changed it all to .cpp files and now it works perfectly.
One thing I ran into is that the (particle) makefiles includes all .cpp files recursively and it does not matter whether I specify CPPSRC, but that is a whole different issue.

Again, thanks for your time!

P.S. for future people reading this, I’ll update my github repo to be some kind of example for others running in the same issues as me. I’ll update my post here when that is done.

It’s great that you found a solution that works for you. It’s too bad I can’t / won’t attempt to bring po-util to Windows.