I liked the idea that Sabersense mentioned in another thread about compiling the name of the config file used into the ‘version’ response for the serial monitor, so created a tiny patch for it.
--- ProffieOS.ino-orig 2022-03-26 14:32:39.000000000 -0700
+++ ProffieOS.ino 2023-01-10 22:12:31.000000000 -0800
@@ -212,7 +214,7 @@
SnoozeBlock snooze_config(snooze_touch, snooze_digital, snooze_timer);
#endif
-const char version[] = "v6.7";
+const char version[] = "v6.7" ", compiled with config file: " CONFIG_FILE;
const char install_time[] = __DATE__ " " __TIME__;
#include "common/common.h"
It produces output like this:
v6.7, compiled with config file: config/vire36os6_PP_Diag.h
I put all of the text and punctuation in the second element of the array so as to leave the version string untouched, and so that you can pull the config file name clean as version[2].
Please let me know if there is a better way to do this, and/or a more appropriate way to submit a patch.
2 Likes
Maybe it would be better to do it later in the file where it already shows the prop, buttons, and install?
Like this:
if (!strcmp(cmd, "version")) {
STDOUT << version
<< "\nconfig: " TOSTRING(CONFIG_FILE) "\nprop: " TOSTRING(PROP_TYPE) "\nbuttons: " TOSTRING(NUM_BUTTONS) "\ninstalled: "
<< install_time << "\n";
return true;
}
output:
02:55:34.412 → 7.x GitHub Master
02:55:34.412 → config: “config/BC_Scoundrel_6.x.h”
02:55:34.412 → prop: SaberBCButtons
02:55:34.412 → buttons: 1
Although since the path is included, maybe “config :” is redundant.
1 Like
Looks like a good idea to me.
Well, people could move the path to something weird…
@NoSloppy, my concern about that approach is that now you are running a bunch of code every time the person types ‘version’ in the serial monitor. The advantage of putting the data into a constant and then just outputting the constant is that there is less to compile, less overall code, and the answer comes back faster (although in this case we’re only talking a few ms).
No sure what you mean.
The code exists there already, just adding a string of the CONFIG_FILE variable uses like nothing additional really?
Seems literally the same as what you posted, just in a more logical way.
People could, but shouldn’t. Regardless, this approach would actually help in that case, because the path is printed.
1 Like
Strings without operators between them are concatenated by the compiler, so it’s still just outputting a constant.
1 Like
Loving this thread!
Am I alone in getting a bit of a buzz when an idea of mine is embraced and implemented into ProffieOS? 
For my part, all I do is search for “const”, then strike out the “const char version[]” line, then re-insert it at the very top of the .ino file below the config define line. (See below). Then every time I want to make a change, I duplicate the config, incrementally add the version number then work on that.
Obviously this involves moving a line of code from its normal place in the .ino file to the top. It’s always worked very well, but this thread seems like a good opportunity to ask if there’s a reason I shouldn’t do this or if I’m inadvertently causing some problem somewhere by doing it?
#define CONFIG_FILE "config/sabersense_kenobi_v3.h"
const char version[] = "Sabersense, Kenobi with crystal, v3.";
You are not causing any problems by doing that.
Simple changes like this are almost always going to work IF they compile. 
1 Like
On my local build, I personalized the Welcome message in common/serial.h and added the version info plus additional stuff…because I can?
if (!SA::AlwaysConnected()) {
STDOUT << "********* Hi Brian! Welcome to ProffieOS " << version << "**********\n";
STDOUT << "For available serial commands, see:\n";
STDOUT << "https://pod.hubbe.net/tools/serial-monitor-commands.html\n";
STDOUT <<
"\nBOOT Volume: " TOSTRING(BOOT_VOLUME)
"\nConfig MAX Volume: " TOSTRING(VOLUME)
"\n" CONFIG_FILE
"\nprop: " TOSTRING(PROP_TYPE)
"\nbuttons: " TOSTRING(NUM_BUTTONS)
"\ninstalled: " << install_time << "\n";
}
3 Likes