As per title: Is it possible to pass a compile-time symbol definition as a flag?
Specifically, I would like to #define a DEBUG symbol to conditionally compile some Serial statements, as well as slightly modify the behavior of the code on startup. If this is not possible, I think I will have to manually comment/uncomment a #define DEBUG statement in every file that I want to test (usually all of them ), and this is obviously not desirable.
Sorry, I wasn’t clear in my first post. I’m using the offline Particle Dev IDE, and I’m compiling semi-offline with the CLI (on Windows). My current compile command is
particle compile photon path/to/project
And I’d like to be able to #define DEBUG from the command line. something like gcc’s -D flag.
Same here. I’d like to test locally on a device that is different from production, or even on another device that’s remote but not prod, and I’d like to easily generate different firmware versions on demand to test these. Editing the defines in the code for each separate compilation is pretty boring, and I’d like to be able to have a simple script call particle compile with specific defines in the command line…
There’s always the option to generate an include file on the fly, but that’s a bit counterproductive…
If you build locally then you can export EXTRA_CFLAGS. The workbench works okay for installing the toolchains and then you can build from any terminal with make. You can probably set that environment in the workbench too, but I don’t use it.
Ended up looking into this, because having compile-time preprocessor definitions can be very nice.
@cmcinroy it looks like this has been included in the particle workbench, under File>Preferences>Settings>Extensions>Particle>Compile Defines
This apparently modifies a settings.json file, where adding data to the particle.compileDefines array allows preprocessor definitions.
e.g.
“particle.compileDefines”:[ “PRD_ID=94” ]
would act the same as
#define PRD_ID 94
A word of caution: from just casual observation, these build settings don’t appear to be stored with the project itself, which means that they wouldn’t be included in any commit/check-in.
Edit: the location depends on if you are editing the User or Workspace settings; User is not stored with the project, Workspace looks to be stored under .vscode.
Hmm. This looks like it has broken or changed, as now the same input is being quoted in the build script (previously PRD_ID=94 is now being entered as PRD_ID=‘94’), which breaks it. This is not cool if true.