Ha! I was thinking about exactly the same thing last night when I looked at mega test cases to see if there is even anything that tests if E0 compiles, but looks like @jeffeb3 beat me to it. Is this a competition now?
1 Like
@jeffeb3 My PR was merged. Probably time to rebase and re-post yours. I asked about which branch to target on Marlin discord and the consensus seems to be that PR-s should be cut against bugfix-2.0.x and then Scott will decide what will go where 
PS! There is no need to switch to a dummy TEMP_SENSOR_0 with EXTRUDERS=0, they will all be automatically cleared anyway. You can set it to 0 for peace of mind 
2 Likes
Okay that is pretty nuts. Seems super simple? You guys are doing things that seem like magic to me.
1 Like
Thanks for the tips. I couldn’t see how to change where it was pointing, and there is not a linear relationship between bugfix-2.0 and 2.0.x… So I just recreated it.
So with setting a few options it is just running those tests or we can use that to build actual branches?
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.
1 Like
Awesome, I understand it I think!
I see him know out all the example configs in a few minutes once and a while so I know he has some scripts for that. He has to.
You’re badmouthing the great UNIX legacy from 70-s son. Dennis Ritchie will turn in his grave …
Regexes are not very robust actually. They do work, as long as you don’t try to parse HTML or do something equally crazy.
1 Like
The shell script approach will probably work. There may be a need to have an example mpcnc config though because use_example_configs command will copy _Bootscreen.h to the right place. Maybe it is possible to push a sample mpcnc config to Marlin. This comes with a commitment to maintain it though.
I was also digging around and found this: https://github.com/wei/pull
With a combination of config file generator scripts, CI and this, it should be possible to automatically trigger builds on upstream updates.
I do software development in Linux (ROS). I have for long enough to not be called “son”. 
Would it be possible to do all of that in a separate repo? One that is just for testing/building/releasing our code, without forking Marlin (or including it’s code)?
1 Like
I may not do it for my current job, but I’ve parsed HTML with regexs before. It can be done. I only ruined part of my soul, and you only have to be a little insane to read it… 
Just pulling yer leg, no offence 
I’ve been working in the industry for 25y now but still when I listen to the types like James Gosling, I feel like a kid looking up to an adult.
Yeah, a lot of people have (including yours truly) however since regex is not capable of expressing the grammar of HTML it’s going to work about 80% of the time and there will always be another piece of incoming data that will “own” your implementation.
This is getting way off-topic though.
I’m still just scratching the surface here. I think it still has to be a fork but forks can have their own “clean” branches so It shouldn’t make a difference… How it promises to work is that it updates a selected branch to match upstream whenever the upstream changes. There seem to be multiple modes including rebase and hard reset. The latter is probably best used to keep a copy of bugfix-2.0.x up to date for example. I’ve yet to try it out.
1 Like
Ok, so I did some research and talked to a few developers on Marlin discord channel.
There is no standard set of scripts to update configs. Every core maintainer has their own favorite way. Some just copy paste lines manually, others, like Scott, use personal scripts.
Of-course I came up with my own version that propagates the last commit to the config tree 
find config -name "Configuration.h" -printf 'for f in Marlin/Configuration*; do git diff HEAD^..HEAD "$f" | git apply -p2 --index -3 --directory="%h"; done\n' | sh
The takeaway here though is that as far as upstream is concerned, the “example” files are the source of truth and config generation scripts are used for testing not for config maintenance. That doesn’t mean these can’t be taken advantage of, but there may be gaps/limitations there. I’m exploring these now.
2 Likes
The testing PR was approved. 
2 Likes
Just to report on some progress here, I did some config updating / generation and I now have four versions of MPCNC/MP3DP/ZenXY configs updated to 2.0.x in different ways. I hope I have time to document and post the results tomorrow.
3 Likes
I created a separate topic as neither EXTRUDERS = 0 nor Marlin 2.0 are a good fit for this discussion.
Ok I’m also seeing EXTRUDERS = 0 not playing nicely with EEPROM. (This is with version 415.)
Send: M502
Recv: echo:Hardcoded Default Settings Loaded
Recv: ok
[…]
Send: M500
Recv: echo:Settings Stored (592 bytes; crc 29379)
Recv: ok
[…]
Send: M501
Recv: Error:EEPROM CRC mismatch - (stored) 29379 != 10704 (calculated)!
Recv: echo:Hardcoded Default Settings Loaded
Recv: ok
The “Error” also causes OctoPrint to go into a frenzy and stop talking (by default). I tried setting EXTRUDERS = 1 and then everything works nicely after M502 & M500.
I think this is the sort of thing where there can be latent assumptions of EXTRUDERS >= 1 all over the place and that’s probably what we’re running into. I can fix the EEPROM issue but it’s hard to know where the other latent bugs are. Unfortunately I think we just have to forge ahead and fix them as they appear.
2 Likes
Here’s a PR against upstream that I think fixes the EEPROM problem with EXTRUDERS == 0.
If you want to apply this change locally, go to Marlin\src\module\configuration_store.cpp
and it’s straightforward enough to apply the patch manually.
2 Likes