Most of the products I build can be run either with an Electron or Photon, which means they may have different dependencies. Is there an easy way to separate these with the project.properties file? Or do I really need to maintain two separate code bases…? This post seemed relevant, but doesn’t quite answer the question…
That depends on your code.
You can write one single code featuring the required compile directives to match all or you break up your code in dedicated modules which can be included according to PLATFORM_ID.
PLATFORM_ID is available at compile time, but project.properties is agnostic to that since it’s not used at compile time but before to that to distinguish what to tell the build environment to do.
You can add the dependencies for both platforms, but only include the required ones in your code.
BTW, can you elaborate what kind of differences in dependencies you expect to need?
I tend to make code that runs on multiple devices use the platform defines by capability. For example, there are defines for a device that has Wi-Fi vs. Cellular, so you know which class to use.
Those are automatically defined, you don’t need to #include anything.
This is especially handy for libraries, so a single library can be used on different devices.
One issue is that project.properties does not have the ability to include different libraries by device type. To get around this, I’ve wrapped good chunks of the CellularHelper library in #if Wiring_Cellular so it can be compiled for the Photon, even though it doesn’t really do much. That allows CellularHelper to be included in project.properties or library.properties in a project that builds for Photon and Electron without errors.
2 Likes
Thanks for the recs! I am doing pretty much exactly what @rickkas7 suggests below and using the differences in platform for fairly simple things like turning on/off cell capabilities or including different project ID’s etc. It seems like the issue is there is one or two libraries I use which aren’t relevant for the Photon, and thus they aren’t wrapped in #if Wiring_Cellular and thus cannot compile on the photon. It seems like the easiest thing to do then is to make changes to those libraries and push the changes and hope they get accepted.
More specifically, it is the electronsample library written by @rickkas7 that is giving me a hold-up. @rickkas7 is there a reason not to wrap these in Wiring_Cellular?
1 Like
Yes I can update the electronsample later this week after Spectra.
1 Like
Awesome. I went ahead and forked the project and made the changes, which brings up another question (let me know if I should break this onto its own thread). Is there a way to include dependencies that link to a specific branch of a GitHub repo rather than having to “publish” the library? Specifically in this instance, I would like to test out the forked version of electronsample without going through the publish process. Is this possible? What is the recommended way to do this? Thanks!
You can upload a library (particle library upload) without making it public.
That way that particular version will be private for you and can be reuploaded as many times you want till you are satisfied with it.
Gotcha - that seems to only work if I am the owner of the library, which I am not. I could re-create the library and copy all the code over, but that seems a bit cumbersome for this use case…hmmm