It is possible to create a simple incrementing "Build Number" purely with Make.

It is a lot easier to deal with a simple number than SHA1 hashes, if it is to be used as parts of file names or showing to Humans in a boot message.

Make will keep the build number in a file that looks like this:

# Automatically generated file - do not edit
BUILDNUMBER=1234

#This section  assigns the name to the above file, once the $(TARGET) name has been established:

# After the target name has been defined
# create a prefix name for the project buildnumber file.
ifeq ($(TARGET),Project_FOO)
BUILDNUMBER_PREFIX := Project_FOO_1234
endif

ifeq ($(TARGET),Project_BAR)
BUILDNUMBER_PREFIX := Project_BAR_4321
endif

# $(TARGET) could also be used directly as the prefix.

Some place before final linking is done place this:

#----------------------------------------------------------------------------
# Auto-incrementing number, which may be used in version numbers:
include $(BUILDNUMBER_PREFIX)_buildnumber
NEW_BUILDNUMBER := $(shell echo $$(( $(BUILDNUMBER) + 1 )))
$(info )
$(info Buildnumber = $(NEW_BUILDNUMBER))
$(info )

# Pass on Buildnumber to C:
CDEFS += -DNEW_BUILDNUMBER=$(NEW_BUILDNUMBER)
CDEFS += -DNEW_BUILDNUMBER_TEXT=\"$(NEW_BUILDNUMBER)\
#----------------------------------------------------------------------------

Then at the point of final linking add the lines that update the build file's
contents for the next run:

# Link: create ELF output file from object files.
.SECONDARY   : $(TARGET).elf
.PRECIOUS    : $(OBJECT_FILES)
$(TARGET).elf: $(OBJECT_FILES)
echo
echo $(LINKING_MSG) $@ [$(TARGET_DIR)/$(TARGET).elf]

[Project Required Linker commands here.  Then add:]

# Update the Buildnumber for the next compile cycle:
echo
echo "# Automatically generated file - do not edit" >
$(BUILDNUMBER_PREFIX)_buildnumber
echo "BUILDNUMBER=$(NEW_BUILDNUMBER)" >> $(BUILDNUMBER_PREFIX)_buildnumber

This does break the idea of reproducible builds.
Since that is already broken I go full in and add the Date and Time of the build:

Some place, such as before main() lives:

const char Date_Prj_str[]       = __DATE__;
const char Time_Prj_str[]       = __TIME__;

const uint16_t BuildNumber_value = NEW_BUILDNUMBER;     /* Build
number that can be found in the .elf file */

uint16_t build_number_get( void )
{
return( NEW_BUILDNUMBER );
}

I agree with you that Rust has many compelling features. After learning and using Rust at my current job in embedded Linux applications, there's something about it that I've not experienced in any other language.  As languages go, the Rust environment stands at the apex of modern developer solutions: build repeatability, library management, versioning, feature gates, deployment, linting, code style formatter, static analysis, cross-platform support, compiler message clarity, documentation autogeneration, on and on ... the list of built-in workflow features truly is long and comprehensively covers so many things experienced developers have spent entire careers creating manually for C/C++.  And then start over from scratch with new toolchains at their next employer, ha!

While you are correct there is no ANSI standard for Rust, it is not the "wild west" one might gather from your comments.  It has always been backwards compatible for me, rather it oddly has the inverse problem of most legacy code - all older code compiles just fine, it's only newer code (usually that library that you too-easily pulled in) that uses constantly improving features, which requires the latest compiler.  As opposed to older code requiring older compilers.  Rust does not deprecate compatibility.

There is something magical about Rust.  It takes a long time to get your code to compile, especially early on.  But then an amazing thing happens.  Your code just works.  It doesn't run for 5 minutes and then crash, it doesn't print garbage in your terminal.  Sure, there are application logic problems, but solving those problems has customer value.  Solving a buffer overflow, type conversion error, concurrency, or undefined math operations due to mismatched types are where many of us have spent most of our careers.  The latter category of problems bring zero product value to customers.  They don't go away entirely, but they are greatly diminished by compile time checks and that decreases the overall cost of development.

After learning Rust, I do wonder if I've ever made a C/C++ program that actually ran how I thought it did.

I haven't used Rust in truly embedded MCU applications yet, however I'm very excited to experience the Rust embedded-hal, which is a well-defined MCU- and middleware-agnostic abstraction that is picking up speed.  With Rust's extremely strong type system and traits, I expect great things on the embedded front in the coming years.

Embedded environments I have worked in have never had an integrated package management system that makes sharing code as trivial as Rust.  It literally takes seconds, not minutes or hours, and is tightly version controlled so you don't get blindsided with changes.

All the pros aside, I can completely agree Rust has risks that should be carefully evaluated.  Engineers with Rust skills are in short supply, the learning curve is steep.  The trade-off between "I can ship crappy C code, I cannot ship crappy Rust code" means there's inevitable linkage between quality and total development time is less severable in Rust applications.  And that limits business and market timing decisions, and is especially painful if agile principles are not applied well organization-wide.

Or, said tongue-in-cheek but frankly - it's not for organizations that don't culturally value quality.  Rust as a technology will swim against the current.

My experience has been the risks are lower in the technical and feature capability side than one might think.  (Recall the library system - it's nascent but surprisingly large, and due to the type, trait features and package management system, code reuse is far more attainable and robust than C/C++. Foreign language bindings also make using legacy C/C++ in Rust reasonably easy.)  The higher risks I see are mostly around resource availability and putting novice Rust programmers altogether on a greenfield project at once.  It's harder to pivot and iterate in Rust if the project requirements are unclear/constantly morphing.  Novice developers will struggle to think in the higher systems engineering plane when they are learning basics.  If the architecture is not designed up front to handle rapid prototyping iteration - you can quickly find yourself fighting the compiler against lifetimes and types, which impedes rapid prototyping.  Again, this risk should be weighted against how well both the engineers and the company are at thinking in small, releasable product quantizations.

For this engineer, Rust has proven its mettle and its widespread adoption seems a matter of when, not if, in the embedded space.  It's in our nature as engineers to graft ourselves into the most efficient systems.  Not today, but I do see an inflection point in the near future.  Many an embedded engineer's pipe dreams of today are delivered on a silver platter by Rust.

The Administration will work with Congress and the private sector to develop legislation establishing liability for software products and services. Any such legislation should prevent manufacturers and software publishers with market power from fully disclaiming liability by contract, and establish higher standards of care for software in specific high-risk scenarios. To begin to shape standards of care for secure software development, the Administration will drive the development of an adaptable safe harbor framework to shield from liability companies that securely develop and maintain their software products and services. This safe harbour will draw from current best practices for secure software development, such as the NIST Secure Software Development Framework. It also must evolve over time, incorporating new tools for secure software development, software transparency, and vulnerability discovery.

Cesanta is looking to fill several positions in the embedded engineering field. Positions are fully remote and fulltime (but part time is also an option):

• C/C++ Software Engineer [REMOTE]
  This position requires strong requirements gathering, design, coding and debugging skills, with a passion for developing high-quality and well-architected software.
• C/C++ Junior Embedded Software Engineer [REMOTE]
  This position requires desire to learn new skills and work on requirements gathering, design, coding and debugging, developing high-quality and well-architected software.

Check us out https://cesanta.com/jobs.html.  Contact jobs@cesanta.com

ABB is hiring a Senior Embedded Engineer. The successful candidate will be in charge of firmware development for power monitoring devices for industrial applications.

You can find the job description here: https://careers.abb/global/en/job/85434682/-Senior-R-D-Engineer-f-m-d-Embedded-Systems

Embedded Engineer 
Rochester, NY 
This design and development position for multiprocessor control systems can see ARM through ATTINY hardware, and software mostly in C. 
Capabilities working in real-time systems within bare metal to small operating systems experience desired. 
FPGA, peripheral interface, and even the occasional web page and analog knowledge are appreciated. 
New product design opportunities are in-process and planned! 
Please apply at: https://recruiting.paylocity.com/recruiting/jobs/All/dab5060f-4102-4ef1-ad68-232f873f47e0/Ambrell-Corporation

Nova Tech Engineering designs, develops and markets automated system for agriculture industry, primarily in poultry and shrimp.  We have a team of embedded developers, and we are recruiting to add 1-2 more to our team. 

https://novatechengineering.applytojob.com/apply/AVVIcXejUV/Embedded-Software-Engineer?source=Our%20Career%20Page%20Widget
https://novatechengineering.applytojob.com/apply/WcMAQtQK2N/Firmware-Engineer?source=Our%20Career%20Page%20Widget

I'm the CTO at Kelvin (dba Radiator Labs), and our mission is to decarbonize legacy buildings. We have a PCBA for our radiator enclosure, and we have more devices coming in our future (Heat Pump, Thermal Battery, Remote Thermostat, etc.)

Looking for a very senior (principal level) firmware / embedded engineer with 14+ years of experience. 

Here's the LinkedIn Posting: # Principal Embedded / Firmware Engineer
https://www.linkedin.com/jobs/view/3505163860/