"pio test -c someconfig.ini" ignores "-c"

[jcw]

• PlatformIO Core.
  If you’ve found a bug, please provide an information below.

Configuration

Operating system: macOS

PlatformIO Version: 4.3.4

Description of problem

pio test -c configs/native.ini gives an error msg.
With pio run -c configs/native.ini, it works as expected.

Actual Results

The platformio.ini file is used, which does not contain a "native" env:

Error: Unknown environment names 'native'. Valid names are 'bluepill_f103c8'

The content of platformio.ini:

[platformio]
extra_configs = configs/bluepill_f103c8.ini

Update: see also https://community.platformio.org/t/pio-test-with-c-option/14731

[jcw]

Anything I can do to help with this? If you point me to the location of the Python scripts, I could have a look perhaps.

(sorry, first time for me, looking into pio itself, and I can't seem to figure out where the scripts live, on MacOS ...)

UPDATE: Ok, found the scripts - I think the problem is in this piece of code. The test cmd is using the run cmd, without run knowing about the overriding -c arg. Note also, that adding an empty [env:native] to platformio.ini (which should not be used!) leads to a different error, but pio is still confused and using the wrong config file.

[ivankravets]

Thanks for the report! Please re-test with pio upgrade --dev.

[jcw]

Many thanks, will do - could you please tell me how to revert back to non-dev releases once this goes into mainline? I got bitten by this in the past, would prefer to avoid ending up in that corner of the room again ...

[ivankravets]

https://docs.platformio.org/en/latest/core/installation.html#development-version

See

To revert to the latest stable version:

[jcw]

Thank you. And I can confirm that it works. The approach I'm trying is a large collection of .ini files in a configs/ sub-dir, one per board type, all loaded via extra_configs and a wildcard in the main platformio.ini file, and then I add serial port choices and special config details there. This makes it easier to share a project for others to build their setup with. So the project repo has no platformio.ini at the top level, just a tiny example. I'm still exploring, but really want to make it easy for people to use whatever board they want.

[ivankravets]

It sounds very interesting. Is this project open sourced? I just want to take a look at your use case.

[jcw]

Sure - https://git.jeelabs.org/jcw/monty

[jcw]

The main platformio.ini can be something like:

[platformio]
extra_configs = configs/[a-z]*.ini
default_envs = disco_f407vg

[env]
test_filter = type

[env:disco_f407vg]
build_flags = -Wno-return-type -DNDEBUG
monitor_port = /dev/cu.usbmodem1462203
test_port = /dev/cu.usbmodem1462203

One minor issue remains: AFAIK, I can't add to the build_flags setting in this setup. It would be nice to have the ini files have all the stuff essential for building as is, and then allow adding more flags in the above (or vice versa: have the ini files add to what is present in the platformio.ini file. But now we're straying into wish-list territory :)

[ivankravets]

and then allow adding more flags in the above

Could you explain in details?

[jcw]

In configs/nucleo_l010rb.ini (dev branch), there's this line: build_flags = -DSTM32L0. I need this for picking the proper code version for that STM32 family, because there is very little uniformity in the different build defaults (in disco_f407vg there's a -DSTM32F4, for example, so that's fine as is).

If I now want to build with asserts disabled, I need to add Wno-return-type -DNDEBUG flags, as shown in the above example. But then one of the two build_flags settings is lost. It would be nice to be able to extend the settings, iso replacing it. This issue is similar to makefile includes. In make, you have += as a way to extend, but I'm not sure that's easy to adopt in what looks like a standard ini-file parser used in PIO.

The same issue can also come up in the [env] approach, if you want to use its settings and extend them slightly.

Yet another example is here, using extends to config minor variants. I can't use [env] in this case, because that would affect all my configs.

I think the underlying issue is really that these config settings are more and more coming from different places and sharing more and more pieces. Which is great, because it helps avoid duplication. But it gets tricky.

Maybe there's a better way to do this. I haven't used [common.xyz} anywhere. The challenge is to keep it simple ...

[ivankravets]

You can also use += but with a different syntax:

[env]
build_flags = -D COMMON_MACRO

[env:myenv]
build_flags = 
    ${env.build_flags}
    -D CUSTOM_MACRO
    

[jcw]

Ah, that's interesting. Goal here is: have a configs/blah.ini ready to use, but without the site-specific info, i.e. serial port choices, and the debug enable/disable I mentioned. There may be a few more choices, but not that many.

Also, note that the config file as is is intended to work out of the box (i.e. no repo changes):

pio run -c configs/whatever.ini

And then platformio.ini is used to simplify this for quick dev cycles. Perhaps this would work:

[platformio]
extra_configs = configs/[a-z]*.ini
default_envs = dev

[env:dev]
extends = disco_f407vg
test_filter = type
build_flags =
  {disco_f407vg.build_flags}
  -Wno-return-type -DNDEBUG
monitor_port = /dev/cu.usbmodem1462203
test_port = /dev/cu.usbmodem1462203

I haven't tried this. In short: top-level ini pulls in everything, then extends some flags, and specifies serial ports.

Thanks for the tip - I'll try a few approaches.

[ivankravets]

Exactly, see [env] common section that was introduced in PlatformIO Core 4.0 https://docs.platformio.org/en/latest/projectconf/section_env.html

[jcw]

Great, thx. Yes, [env] is a very useful addition. And the above would scale nicely to [env:dev1], [env:dev2], etc to let me pick exactly the small subset of boards I am currently focusing on - even if configs/ ends up being huge.

Thanks Ivan. Fantastic job by you and your team.

[ivankravets]

Thank you too for the reports and ideas!

Happy coding with PlatformIO! ❤️

[jcw]

Just to finish off (I can continue the forum or start a new issue, if needed) ...

The new 4.4 setup is indeed very flexible, but including all boards and using only one is slightly inconvenient: 1) a very long list of "IGNORED" lines at the end of a run (even more at the end of a test), and 2) those lists do not appear to be sorted in any way, I suspect that it's the directory order of the extra_configs wildcard. Perhaps a future option in the [platformio] section to reduce the output by omitting reports about things not done could solve this :)

A completely different approach would be to load the configs only when mentioned, i.e. have PIO know about the configs/ dir (or whatever, that's the name I've been using), so if you had an entry called [env:blah.ini], then PIO would look for a file by that name, and then use the settings to expand on what's in that config file. Or perhaps have an optional load_configs = dir flag in the platformio] section, to trigger this sort of on-demand loading behaviour.

As before, what I'm trying to solve is a way to have tons of configs (a growing / contributed set of files, presumably), while keeping the contents of platformio.ini limited to the one or two boards I'm actually using.

[ivankravets]

only one is slightly inconvenient: 1) a very long list of "IGNORED" lines

We decided to name next release as 5.0 because there are some changes which remove fucntionality that was in PIO Core 4.0. Could open a feature request and we will implement this in 5.0. I also don't like this long list with envs when user builds only 1 env.

Thanks!