Library import flattens directory structure? [WORKAROUND]

Thanks @Dave for responding an relaying my ping :wink:

To safe Wojtek and Joe some reading:
It would be nice not only to distinguish between SPARK or not but also between WEB_IDE and Spar Dev/CLI, since Web IDE requires a different folder hierarchy for #include than the others.

Hi @ScruffR,

yeah this is a known issue. But instead of adding workarounds (like #defining env) it will be better for all developer facing tools to have the same way of importing. It is something we have to figure out soon.

As for workaround, SPARK is defined in both Build and Dev so this wouldn’t really help.

I know :anguished:

But since @Dave mentioned SPARK in his post, I tried to incorporate this and point out that there would still be a need for something else.
Sure, best would be one behaviour over all dev envs.

@ScruffR @Dave @mdma

Any update on this? Do I absolutely need to flatten my directory structure in-order to support for WebIDE? I have an intricate directory structure within my project (and this easily builds when I make with https://github.com/spark/firmware and program using dfu-utils).

Do I have to flatten this (it’s going to be a lot of work, and at the same time I will lose build capability for another platform)? Are there any build flags that I can use with #ifdefs for Web IDE support?

Any help is sincerely appreciated.

1 Like

Don’t put your finger in open wounds :weary:
I’ve been proposing this idea for ages but always got staved off that there will be a one-for-all IDE solution, but I’m still waiting.
If it were introduced shortly after I first mentioned it, it would have saved a lot of people some work and grief.

If you look in this forum how often people stumble over incompatible #include statements in libraries that either trip up Particle Build or Particle Dev :tired_face:

1 Like

I hope there is a way around this, this is very important to me and I am sure to a few others! I don’t want to render my code base unusable.

Cmon!!

1 Like

Just chiming in that I’m bumping this one again with the library folks.

Thanks,
David

1 Like

@jersey99 we started working on implementing new version of libraries (which won’t have this limitation and will unify how they work in both local and web IDEs). It took us into new areas like revisiting cloud compiler infrastructure which made it stretch longer than we planned. I feel your pain and we’re working on mitigating it :smile:

1 Like

Any updates on this? (The SparkCore version of the FastLED library has fallen pretty far behind the main library repo - and the need to flatten structure is causing problems again).

Any chance of Spark and Arduino unifying their requirements for libraries and layout? (The need to maintain a separate directory layout and organization and repo has effectively made the spark/photon bastard step children).

(This checkin brought to you by dealing with some photon specific issues and remembering why I don’t have this in my regular library testing/dev rotation)

You actually can now keep the structure, you just need to provide a particle.include file to tell which (“nested”) files to upload.

Can particle.include also be used for submitted libraries - or is it only for code directly in the project?

Nope, you have to download the files into your project folder.
The subfolder you place the files in has to be named and structured as it is on Build, otherwise you’d need to adapt all include statements accordingly.

Does build allow libraries to have nested structures yet? The spark version of FastLED is significantly behind the mainline version because I’m using nested directories to manage the code/structure and I don’t want to also have to juggle changing the entire directory structure for particle, so I’ve been holding off (the base directory layout being different from what is used in most other environments (and it being rigid about that) is enough of a thing to work around)

I’m trying to find an answer to this myself, it’s disappointing that I can’t use the latest FastLED features on the Photon, but I completely understand why you don’t want to manage two code bases when one should do.

Back in October:

From last week - looks like this isn’t supported yet:

The library example repo has a V2 branch, but hasn’t been updated since September:
https://github.com/spark/uber-library-example/tree/feature/libraries-v2

It’s using a library.properties file like Arduino libraries, but doesn’t specifically mention nested folders in the README. Fingers crossed that they release this soon, and include nested folder support.

1 Like

@dgarcia Have you thought about creating a script that flattens the library, so you only have to maintain one repo, and the Particle-specific repo is just a modified copy of the main repo after applying the script?

I really wish Particle could implement full support for the Arduino IDE and Builder, like the RedBear Duo, or ESP8266. I’m not sure if there is a hardware limitation preventing this, or if it’s all software.

The firmware building and IDE is currently getting some attention behind the scenes (as there was a new push for Dev a few hours ago).

Any update on this? I’m getting started with the cli after using the web IDE, attempting to use a handful of libraries, and Particle is breaking on the most basic of directory support.

$ grep include gps-electron.ino 
#include "SparkFunMAX17043/SparkFunMAX17043.h"
#include "SparkFunMicroOLED/SparkFunMicroOLED.h"
#include <TinyGPS++/TinyGPS++.h>

$ particle electron compile gps-electron.ino SparkFunMAX17043/* SparkFunMicroOLED/* TinyGPS++/*
Compiling code for electron
Including:
    gps-electron.ino
    SparkFunMAX17043/SparkFunMAX17043.cpp
    SparkFunMAX17043/SparkFunMAX17043.h
    SparkFunMicroOLED/SparkFunMicroOLED.cpp
    SparkFunMicroOLED/SparkFunMicroOLED.h
    SparkFunMicroOLED/SparkFunMicroOLEDFonts.h
    TinyGPS++/TinyGPS++.cpp
    TinyGPS++/TinyGPS++.h
attempting to compile firmware 
pushing file: gps-electron.ino
pushing file: SparkFunMAX17043/SparkFunMAX17043.cpp
pushing file: SparkFunMAX17043/SparkFunMAX17043.h
pushing file: SparkFunMicroOLED/SparkFunMicroOLED.cpp
pushing file: SparkFunMicroOLED/SparkFunMicroOLED.h
pushing file: SparkFunMicroOLED/SparkFunMicroOLEDFonts.h
pushing file: TinyGPS++/TinyGPS++.cpp
pushing file: TinyGPS++/TinyGPS++.h
Compile failed. Exiting.
gps-electron.cpp:1:47: fatal error: SparkFunMAX17043/SparkFunMAX17043.h: No such file or directory
 #include "SparkFunMAX17043/SparkFunMAX17043.h"

.

I just want to +1 this as I’m currently working on a library with a similar goal of FastLED to support multiple platforms and have arranged files in a tree of folders. The idea of a non-master branch option for community libraries and a non-flattened structure is very appealing.

1 Like

It looks like you found part of the solution I did, as far as getting the subdirectories to be included, but then you have to do the odd thing of making the call from the .ino file to not include the directory name. (Yup, that’s weird and the fix suggested above should be the final solution, but this works.
I got the sulution from another thread on this forum but I just can’t find it right now so I’'l put out my own. Every reference i have seen to particle.include says you nedd to list each item but this syntax works (I haven’t tried with multilevel nested directories but let’s see what happens:
The file “particle.include” should have this:
#particle.include
# from current dir
*.h
*.ino
*.cpp
*.c

# and from any subdirectories
 **/*.h
 **/*.ino
 **/*.cpp
 **/*.c

… But then you need to remove the directory reference from the "#include line"
I am successfully using this with the SdFat library with the library in in "SdFat/SdFat"
My “#include” line in the .ino file went from:
#include #include "SdFat/SdFat.h"
to:
#include "SdFat.h"
and it all magically works:
I’m speculating that it grabs all files referenced and drops them into a single flat virtual directory on the server and then compiles. So you can keep a directory structure locally but treat it like a flat directory for referring to the files. Obviously this leaves something to be desired, and could result in filename conflicts that are difficult to debug but it does work as a workaround.