Inheriting lib_deps in platformio.ini

[crankyoldgit]

Per your comment/question in your YT video: https://youtu.be/UZxY_BLSsGg?t=898

Have a look at this example for one way to do it.
https://github.com/crankyoldgit/IRremoteESP8266/blob/9d25486ea932f599bc44d175c7293dac4167fae4/examples/IRMQTTServer/platformio.ini#L13-L33

Btw, thanks for using our library in you project.

[davepl]

Cool I'll see if I can replicate that next time I tinker in there!

Thanks for the lib! I had previously been hacking up the older solutions to turn them off for OTA uploads, but your addition of a a function to turn off the remote made it work for me!

[robertlipe]

Interestingly, I just came across this now, years later. I've had a PR in for discussion for a long time while we've tried to socialize the effects of this and kind of coasted to a halt. I've tried inheriting flags much like you describe but can't seem to make this spoonful of medicine palatable. (It's overall painful enough to me that it's almost worth forking the project. Watching this project fetch and build libs that the linker then tosses is killing me.) Also of interest, IRRemote is one of our pain points.

IRRemote is slow to compile. I'm sure you know this. It compiles a ton of things this project just doesn't need. (We really only care about NEC dumb media remote, so we could honestly probably just use the ESP-IDF [facilities](https://github.com/espressif/esp-idf/tree/master/examples/peripherals/rmt/ir_nec_transceiver as we never transmit, don't care about European air conditioners, etc.), but let's not go there yet.)

I proposed making the presence of IRRemote in libs_dep conditional based on whether or not we actually wanted IR support for a given env. Unfortunately, the master switch for ND isn't up in platformio.ini, it's in include/globals.h. So IRRemote is always in lib_deps and always compiled, whether it's referenced or not. :-( Individual build types set flags that are examined in globals.h that control whether or not we use IRRemote.

I thought this was upside down. I started pulling at this thread in #500 and either pulled too deeply or not far enough (my vote), but it's kind of stalled out.

My plan was to make the top level platform.ini env set BOTH the remote_flags (-DUSE_REMOTE) AND add ${remote_flags.lib_deps} to lib_deps, but only if wanted. This gets globals.h out of the decision process totally. So I kind of turned it inside out and that went over like a lead balloon.

It's a bit of a drag to have to toggle both lib_deps AND build_flags, but it's by no means the most terrible aspect of scons sticking out of platformio's groady build system.

The awesome thing about teaching platformio.ini inheritance of lib_deps and build_flags is that it makes it possible to create new build types completely from the command line. Want four builds that represent {effect FOO = a, b, IR_REMOTE = true, false}? It's merely a scripting exercise; you don't have to edit globals.h at all. Want screens? Now your 22 matrix is 22*2. You can see how terrible this gets.

The awful thing is that it's very heavy with fragile boilerplate in platformio.ini, as seen in my PR. Keeping build_flags and lib_deps in sync isn't easy or bulletproof. You can generate a combination that sets the -D but doesn't set the -L -l, so it won't actually work, even if it links. That's frailty we don't really need.

I really really don't want to compile IRRemote when I'm not using it (#sorrynotsorry). But IRRemote is only one of about a 5-10 similar flags in this project that lead to combinatorial explosions.

I tried to pitch the project on inheritance of lib_deps and build_flags and so far, have failed. Since one of the poster children for my failure happens to be crankyoldgit/IRremoteESP8266, it seems fair to question it here since you're pitching that very design.

Platformio's build inheritance is, well, not great. When people fuss about it in the community, the response is that it's working as designed.

Can you point to large, real-world platformio projects (that almost seems self-contradictory...) that use flag inhertance in the way you're describing here? Hopefully, I can learn something from their approach that both solves the problems that I think we have in ND and that overcomes the objections of the reviewer to my attempt to push lib_deps inheritance into platform.ini instead of a global.h file and just blindly building everything and letting the linker toss it at the end.

Advice welcome.