Avoid need for USE_CUSTOM_H flag

[cconde]

As a suggestion I would have always a custom.h file and it would be always included at "all.h"

The HEAD version would only have some comments on its usage, so no code at all will be included and any build will have the same result as not defining the inclusion of flag on the "platformio.ini". People like me, that tend to use it would just ignore it from git operations and code inside custom.h.

I feel very annoying to have to discard my changes (this flag inclusion on build flags) every time I want to get in sync with the HEAD version, and then editing platformio.ini again to keep my customizations.

By the way, "custom.h" would be omitted during the Two Step Upgrade process, I guess...
https://github.com/xoseperez/espurna/wiki/TwoStepUpdates

If you feel interested I can prepare a pull request.

Thank you Xose for your excellent job!

[lobradov]

We did think about "custom" images that would always be present in platformio.ini and would be placeholders for your own images. Problem is - there's quite a few variances to be covered (board type, flags...) so we decided to put that idea on hold and think about dynamic way of generating platformio.ini depending on what you need. Another route is to have ability in PlatformIO to include external ini files - I opened a feature request on PlatformIO: platformio/platformio-core#1590 Finally, few people from here are experimenting with dynamic environment creation using scripting, that would allow us to "inject" settings into platformio and hide custom images from git. so - it's work in progress, stay tuned. Until then - manually git fetch && git merge so you don't overwrite your environments.

…

On 24 April 2018 at 09:43, Carlos Iván Conde Martín < ***@***.***> wrote: As a suggestion I would have always a custom.h file and it would be always included at "all.h" The HEAD version would only have some comments on its usage, so no code at all will be included and any build will have the same result as not defining the inclusion of flag on the "platformio.ini". People like me, that tend to use it would just ignore it from git operations and code inside custom.h. I feel very annoying to have to discard my changes (this flag inclusion on build flags) every time I want to get in sync with the HEAD version, and then editing platformio.ini again to keep my customizations. If you feel interested I can prepare a pull request. Thank you Xose for your excellent job! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#810>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcWpOhcJIWa6QdoVjgRgEx54ekEVqxj6ks5trtedgaJpZM4ThKNG> .

[ivankravets]

Could someone explain to me what is wrong with @platformio or how can we improve it?

Have you seen http://docs.platformio.org/en/latest/projectconf/advanced_scripting.html ? You can automate build environment using Python language.

[lobradov]

Nothing wrong (on the contrary ;), but might have room for improvement.

Advanced scripting is one way to solve the issue (see "dynamic environment creation" above), but I was exploring other routes, including platformio.ini #include-like behavior described in platformio/platformio-core#1590

While we can write local scripts for espurna project only, I wondered if you would be interested in adding more functionality to PlatformIO.

[ivankravets]

Great! 😊

I like the idea of #include "custom.ini". I will think about the technical details. I like how GCC preprocessor works, it replaces all #include occurrences with a content of files. Would be good to implement the same. In this case, you can use #include syntax in any places, not only via extra_env_files =

[lobradov]

I prefer #include (doesn't have to be restricted to environments...) but was thinking about solution that would fit more naturally into existing platformio.ini logic, hence clumsy attempt of extra_env_files.

Just please make sure it accepts directories and wildcards, like:
#include envs/*.ini

:)

[ivankravets]

Just please make sure it accepts directories and wildcards, like:
#include envs/*.ini

Please add this to platformio/platformio-core#1590

[proddy]

I have a similar challenge as @cconde

I'm extending espurna for my homegrown ESP8266 based devices and set both -DUSE_EXTRA and -DUSE_CUSTOM_H in platformio.ini which obviously gets discarded when I fetch the latest from GitHub. Hopefully, platformio/platformio-core#1590 would fix that if/when it gets implemented.

Then for my module a separate .ino file with the method extraSetup() to kick things off.

Works fine. Problem though is the custom HTML I wish to add to /code/html/index.html to control my particular settings. Is there a nicer way to include custom code in the html files?

[xoseperez]

@proddy In #764 we were talking about different possible ways (not yet implemented) to solve the HTML part. The one I like the most is having the ability to selectively include HTML/JS code during the web interface build process...

[cconde]

@proddy have you solved the discarding changes issue? I've just fetched the new version and gone through rewriting my changes...

[proddy]

@cconde no I haven't looked into this yet.

[peterhoeg]

You can use direnv as a workaround.

1. Install https://github.com/direnv/direnv
2. Create .envrc "one-step-up" from where you have the espurna repo checked out with these contents:

export ESPURNA_FLAGS="-DUSE_CUSTOM_H"

3. Allow it to run direnv allow

The platformio.ini file in 1.13.3 then picks up the environment variable.