Marlin: [FR] structured configuration via __has_include

[Andrei-Pozolotin]

Description

Perhaps a time has come to migrate to
a more structured configuration via __has_include, __has_include_next, etc.:
https://en.cppreference.com/w/cpp/preprocessor/include
which is available since GCC 5:
https://www.gnu.org/software/gcc/gcc-5/changes.html
and works with current platformio/toolchain-gccarmnoneeabi

Primary Benefits

End users do not have to deal with merge of Configuration.h,
and can focus only on maintenance of User_Configuration.h, i.e.:

// maintained by core developers
#include "Configuration.h"

// maintained by end users
#if __has_include("User_Configuration.h")
   #include "User_Configuration.h"
#endif

Similar approach eventually should apply to pins/pins_BOARD.h.

[ghost]

I like that.

What puts me off using the latest v2 build is having to transfer all my doings from my current config and pin files to the new ones.

[Andrei-Pozolotin]

one can introduce split now and start applying changes incrementally, by slowly reverting Configuration.h to the master state, while moving custom changes from Configuration.h into User_Configuration.h, as follows:

• Configuration.h#L2115
• User_Configuration.h

[marcio-ao]

Wouldn't they get warnings about redefining things? I see those a lot and have to use #undef

[ManuelMcLure]

Wouldn't they get warnings about redefining things? I see those a lot and have to use #undef

A way around that is to include Configuration_user.h _first_ and then have Configuration.h only set values that have not been already set by the user.

[ManuelMcLure]

That would require that every entry in Configuration.h and Configuration_adv.h be wrapped in #ifndef/#endif, however.

[comps]

See the discussion in #12541, there's probably a much easier and less compiler-dependent way of doing it - just leave everything commented out in Configuration.h / Configuration_adv.h and set the defaults in various Conditionals_post.h files (the main one, the LCD one, etc.), as is already done with some config options:
https://github.com/MarlinFirmware/Marlin/blob/2e3d121ac434a990e69c3a068991681f2e4563ce/Marlin/src/inc/Conditionals_post.h#L1118-L1131

That way, you could just have a custom version of Configuration.h / Configuration_adv.h that defines only what you actually change from the default.

[ManuelMcLure]

Unfortunately that leaves us with the same problem - keeping your personal Configuration.h/Configuration_adv.h up-to-date with upstream when you do a pull to update your sources. The advantage of Configuration_user.h is that it keeps the user's configuration out of files that change from version to version.
I know that merging upstream changes into my configuration files when git stash pop fails to auto-merge is one of my least favorite things about Marlin.

[davidelang]

On Thu, 18 Apr 2019, ManuelMcLure wrote:

Unfortunately that leaves us with the same problem - keeping your personal Configuration.h/Configuration_adv.h up-to-date with upstream when you do a pull to update your sources. The advantage of Configuration_user.h is that it keeps the user's configuration out of files that change from version to version.
I know that merging upstream changes into my configuration files when git stash pop fails to auto-merge is one of my least favorite things about Marlin.

to avoid this, the upstream repo should not have this file in it, but rather
have a .default version of the file. During the make process, check if the real
file exists, if not, copy in the default file and continue, if it does exist,
use it.

This can result in a headache when there are new things that are required to be
in this file, but there is no way to both auto-update a file and keep local
changes to the same file.

David Lang

[psavva]

• This would also eliminates the need to your each example configuration file when a new configuration item is needed.

• The user defined file would be somewhat cumbersome to add a new configuration item. The users would have to know what parts of the default configuration file to copy to their personal configuration file, and not all 3D printer users are programmers... That could be a deal breaker unless you see it done differently. Is: user friendly

[ghost]

I thought I'd write my own configurator for Marlin as I find it a real hassle transffering my settings over at times.

Only just started it but I'll post the program and source for anyone who wants it once I get it usable if thy wish.

It scans in the various files and does what it needs to do with them. I'll make it so that you can save your desired settings in file so that you can automatically apply those settings to any new builds of Marlin at the press of a button, whilst leaving any new settings that should appear in the config files etc alone, maybe highlight them for the user ?

The beginnings ..

[Andrei-Pozolotin]

write my own configurator

1. great idea, I played with this that as well
2. I envision a web application which can commit changes back to user's github repo

[thinkyhead]

I favor a configurator approach, as well. Especially as we can pull out the metadata and even parse and use the sanity-checks to do automatic migration of settings from one version of Marlin to another and to generate documentation (starting-point). I have also started on this very project, using Javascript because it is universally accessible. https://github.com/thinkyhead/MarlinConfigurator

I didn't add the architecture level for Marlin 2.0 yet, but that's a good idea.

[ghost]

Cool, go for it thinkyhead :)

I do everything in C/C++, but I think Javascript may be better, particularly for cross platform use.

[thinkyhead]

It definitely has its advantages, including the aforementioned ability to interact with Github API, and all the other stuff browsers now do as well as native apps. My Objective-C skills feel so redundant now.

[thinkyhead]

All configuration-oriented work is now at:
https://github.com/MarlinFirmware/Configurations

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.