Platformio.ini for local building

, ,
1

When trying to get a local build environment stable for our code, the only advice I can get is regarding the platformio setup being “wrong”, but examples of what’s “right” look just like what we already have and everything is still “mixed up” somehow. This has made getting triage help difficult, especially when suggestions tend to focus on example code that’s not in use (and I make everyone aware of this).

One of the sticking points seems to be some hard distinction being drawn between a “project” and a “library”, which is just semantics to me, as this is all c++ code and these terms are not technical. Currently we have a directory structure like this:

clusterduck protocol/
├─ docs/
├─ src/
│  ├─ radio/
│  │   ├─ Lora.cpp
│  │   ├─ Lora.h
│  ├─ utils/
│  ├─ routing/
├─ tools/
│  ├─ example_select.py
├─ .gitignore
├─ library.json
├─ platformio.ini
├─ README.md

This mirrors what was already done in one of the “right” projects that was shown to me in ESPAsyncWebServer. I’m currently working with the source tree at this state. I may post a link to a fork later.

What I need right now are specifics and not vagueness about “project” vs “library” and “it’s all messed up so fix it”. This is not a hobby project but something that’s in production and currently right up against a new major release (so don’t bother with the master branch of the repo). I can’t afford to make every change right this moment, but need direction on what changes.

2

I have created an example for you that correctly separates the library code and the examples used for local build.

Take a look at the settings in platformio.ini and compare them with your library.

3

What exactly is the symlink://./ line doing and how would ${env.build_flags} do anything when there is no build_flags under [env]?

Also, why remove all files from [env]'s build_src_filter?

4

symlink:// is the successor to lib_extra_dirs - See lib_extra_dirs — PlatformIO latest documentation

Good catch, my mistake. I used the wrong setting. I wanted to use build_src_filter. I’ll fix that.

You need to change your perspective. Look at the whole thing from the point of view of a project, not a library! PlatformIO builds projects!

There are two sample projects: “example1” and “example2.” The settings apply to these two “projects.”

First, all directories for source codes are removed -<*>. Then, only the directories for the respective projects are added again ( +<../examples/example1/src/*> and +<../examples/example2/src/*>).

Both examples include the library via lib_deps = symlink://./.

Translated, “lib_deps = symlink://./” means “Include the library located in the base directory.”

Does that make sense to you?

5

That makes sense. I’ll have to see how this works once I resolve some issue regarding std::optional not being recognized by the compiler.

6

To be able to use std::optional you might need to change to a newer framework and toolchain version. This can be done by using pioarduino’s espressif32 platform.

7

I tried that and it seems to have worked after also putting in -std=g++2a.
But I get this:

image
image593×222 31 KB

There seems to be something in Platformio that doesn’t recognize what to do with -<*>. But the build will proceed if I take that out, so i’m not sure if it would have done anything.

I’m trying this build on something much smaller that uses the above repo as a dependency: GitHub - BrentonPoke/QuackPack-DuckGPS

The thing I’m don’t get is how this is actually different from what we’re already doing. We were already using the symlink thing, and after that, the only other thing was the build_src_filter, which doesn’t seem to really be necessary. I need to know how much of this is about style and how much of it is actually required.

8

No. Don’t include the build_src_filter in the build_flags. The build_flags are passed onto the compiler (GCC/G++) on the command line, the build_src_filter controls which source files are suppoes to be built. Just delete line 39 and see docs