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.