Marlin and github have done all the complicated stuff. Adding that test was pretty simple once I saw what was going on. Look at this:
This sets their configuration back to default, at the start of the test:
restore_configs
opt_set
changes the value of a #define that has an argument.
opt_set MOTHERBOARD BOARD_RAMBO
opt_set EXTRUDERS 0
opt_enable removes the //
opt_disable adds the //
.
opt_enable S_CURVE_ACCELEARATION
opt_disable MIN_SOFTWARE_ENDSTOP_Z
Then the run whatever tests they run against the source code it just edited. I know it at least compiles it with platformio. I don’t know if they also do more tests, but they could.
exec_test $1 $2 "Rambo CNC Configuration"
These scripts are pretty “simple” too. They look terrible, but they are based on the assumption that the configuration is structured in a certain way. And they enforce that. Then, they just use sed, which is one of the least intuitive programs ever, but it is robust.
The scripts are all in buildroot/bin. (You’ve had a brain all along!). Look at this one for opt_set:
It’s only 3 lines (3 terribly nasty lines).
So, what I’m thinking is, we can do something like make a script that will look like this:
restore_configs
opt_set MOTHERBOARD BOARD_RAMBO
opt_set EXTRUDERS 0
...
make_zip MPCNC_Rambo_T8_16T_LCD_DualEndstop
And you could run that script in any checked out version of Marlin, and it would build up your release .zips.
Or, we could have somebody like travis do it. I think this is close to what Anttix was suggesting. We may disagree on some details, but it might really help. The best part, IMO, is that we might be able to get away with branches only being for versions, and these configurations being reserved for just the .zips.
The other way to do the configuration is to keep a Configuration.h and Configuration_adv.h in the examples. But then when they add #define R_CURVE_ACCELERATION
, our example would need to be updated. I’m sure you know that pain. They must have a way to build those example files with these scripts.