As late as last night I was able to use Particle.variable without difficulty. All of a sudden I got a compile error, even on a program that was unchanged (i.e., I clicked Verify twice in a row without edits). I was briefly getting compile errors using Time. as well, but that failure was transient and went away overnight.
I eventually found a year-old(!) bug report about this, and suggested fix, which worked:
What I'm wondering is why this is a transient error. I compile; it's fine. I compile again without changing the program; it gives this error. I wait overnight and compile again; the Time error disappears, the Particle one does not. 24 hours later the Particle error persists. I change the firmware setting and all is well.
But given that I never changed the firmware reading before, how did it ever compile? I'm starting to imagine a cloud of compile servers, all running slightly different compilers…and that's kinda' scary.
For the benefit of others who might find this thread using a search engine, here's the concrete error message I got:
In file included from ../inc/spark_wiring.h:29:0,
from ../inc/application.h:29,
from dummytestbed.cpp:2:
../../core-common-lib/SPARK_Firmware_Driver/inc/config.h:12:2: warning: #warning "Defaulting to Release Build" [-Wcpp]
#warning "Defaulting to Release Build"
^
dummytestbed.cpp: In function 'void setup()':
dummytestbed.cpp:4:5: error: 'Particle' was not declared in this scope
void loop();
^
make: *** [dummytestbed.o] Error 1
That might be due to the combination of fact that the build farm consists of many servers and you never know which one you hit, and that updates to the build farm might take some time. So once you might hit an already updated server and next time you hit one that's not yet up to date.
Either way you might get an error due to deprecating things that used to work (e.g. Spark vs. Particle) or using features not yet available on servers with pending update.
And then there is the omnipresent risk of the Wiring preprocessor tripping. Which can cause the weirdest errors and often enough clear up by adding/removing a blank line from the top of your sketch.
Another possibility for that particular error might be that you have that code in a .cpp file (rather than .ino) or used #pragma SPARK_NO_PREPROCESSOR without #include "Particle.h".
Just add that include for safe measure.
Other than that, we'd need to see more of your code.
These are all useful, thanks. I was in a .ino file. But the others sound plausible. The lesson I’ve learned is to just be explicit about firmware versions from now on, and hopefully that will take care of it.
Separately, I’m especially baffled by the compiler error messages, which are often nonsensically off target especially with line numbers and code fragments reported. I wondered if there was a pre-processor somewhere that was causing this. Your mention of the Wiring preprocessor makes me think this is indeed the culprit. I pity the inexperienced developer who takes the compiler’s output seriously.
You just said it. The preprocessor does add several lines of code (e.g. the noted include and forward declarations) before the compiler gets to it. But the reported line numbers still fit the actual location, just the excerpt is off.
If you use #pragma SPARK_NO_PREPROCESSOR and add #include "Particle.h" and function prototypes that issue will go away.
At least on the cloud compiler version I’m using, only the #include line was essential. The #pragma resulted in warning: ignoring #pragma SPARK_NO_PREPROCESSOR [-Wunknown-pragmas], and the function headers weren’t necessary (even when I added extra functions to the program). But maybe there are other situations where the others are also useful, so it’s good to know about all of them.
Btw, wouldn’t it be really nice if the example programs on the build site included these, given that they’re not at all “discoverable”? Sure, there’s an argument to be made for “don’t complicate things for the beginning user too much”, but (a) they’re being plunged into C — life’s going to get rough sooner or later, and more to the point (b) getting baffling error messages hardly seems like a prescription for a comfortable beginner experience. Those example programs are so extensively documented, anyway… Not sure how to bring this to Particle’s attention.
That's normal, since at the point where the compiler throws that warning, the proprocessor has already been skipped and the #pragma has no other purpose than that.
The function prototypes are only required if you need to call a function before it's implementation (wherever standard C/C++ calls for forward declaration).
Your suggestions are valid, but libraries are contributed by all kinds of people with different skill levels and variing inclination to adhere to guide lines
