Feature request: A more flexible way to configure builds.

[mk-pmb]

Missing feature

An easy way to generate app/include/user_*.h from config presets that can inherit and override each other. At the very minimum, let's do that Debian priority config thingy where a bash script sources all [0-9][0-9][0-9]*.rc from some directory in alphabetical order. (And I say bash because in that case we should use a config dictionary, not export top level environment variables.)

Justification

Look at the sed commands in nodemcu-custom-build. They're clearly a cry for help. While I might help with making the sed stuff more readable, I'd prefer we dig deeper, to the root of the problem.

Workarounds

I'm currently trying to roll my own 3rd party config wizard, but with the current user header files approach it's a mess to even confirm compatibility of firmware and wizard versions.

My approach

… would be to combine this with #2989, add a top-level directory build-config.default with some lua files that describe available options, and a top-level directory build-config.custom where users can put numbered subdirs with numbered config override lua files. (Having the subdirs should make it easier to docker-mount or symlink independent config patch collections without messing up their internal numbering.)
Since I'm new to LUA, in case LUA turns out too cumbersome, I might use python or bash as a temporary draft just so we have a better basis to talk about.
Would that be a good start?

[marcelstoer]

Look at the sed commands in nodemcu-custom-build. They're clearly a cry for help.

Not really, no. Everything we do here in the firmware project should focus on what developers need and what they are already familiar with. If that makes it difficult for my cloud builder and the Docker image then so be it. I can easily accept that as it's a very special niche use case.

This is not to say that the firmware config mechanism with its .h files couldn't be improved. Apart from Terry's very helpful inline code/config comments very little changed since we took over maintenance from the original authors in summer 2015.

[mk-pmb]

Anyone who uses custom config, has an expectation about the results, and can verify it, please help me learn what people really want customized, and (soon) whether my Github cloud builder can deliver it, by sharing your config files.
My idea is to first get it working with legacy config methods, then figure out nicer ones.

[uDude]

I have an old note to use kconfig for this since it is the default in the linux kernel, busybox, LFS, and others. I literally just saw the note and was looking to see if any discussion on the topic had occurred.

[danielmconrad]

I came here to propose the same idea as @mk-pmb. A docker image that’s dependent on having a local copy of a git repo is very unconventional. If the firmware were configurable via an rc file, it would allow others to put together a full end-to-end application development environment. I know I may be biased, but I believe that happy app developers usually means good things for the ecosystem.

[mk-pmb]

@danielmconrad, thanks for chiming in! :-)
I'm not sure if you found it already: nodemcu-firmware-build-as-github-action can already build firmwares based on just config files in a Github repo. The config file format is still very close to the original (mostly just filename changes), and not as modular and flexible as I hope I can make it, but a step towards. I will definitely try to take it further once I have more time.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mk-pmb]

I'm still interested.

[uDude]

I'm not one of the devs .. so if I tick you off, take umbridge with me, not them. This is an awesome project. I won't address your experience of not cloning and configuring from GIT, as we clearly have different experiences. As far as this project goes, some modules are written in C and some in lua. Those modules written in C are typically linked into the firmware while modules written in lua are yours to pick and choose from. Since linking is currently done at compile time, it is difficult to just provide a simple runtime RC file. Yes, I know that we can do runtime linking of modules but that takes effort from the 4-5 devs that may be periodically supporting this project. I am not one of the devs and will never be as I will likely leave this lovely world in the next couple of years. I actually think they have taken development in some areas that help this language eclipse the capabilities of either uPython or uJS. Indeed, with the XIP of RO pages in flash they have freed up a ton of memory for our programs. They embarked on a major effort to provide a lot more information for debugging lua projects (my early gripe and why I quit using this project early on -- the new work being why I'm back). They also have been performing a massive port to RTOS which will ultimately make the language more portable across the FreeRTOS ecosystem. I do agree with you --- anything lowering the bar for more devs would benefit the project. I just understand that the guys are seriously fatigued. That said, if you have a solid proposal and can provide support for your proposal, I'm sure people would listen. Do understand if they honestly and directly critique your proposal, after all they will be the onces providing long term support. Terry et. al., are never intentionally mean, they are just overworked. My first lucid day in three weeks -- I'm happy at least to respond in this way, I hope I did not offend, uDude

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mk-pmb]

Haven't had time to make progress, but I think it's still a good idea.