Add the nodemcu-firmware version hash to the signon.

[cwrseck]

Running the current (20190405) NodeMCU build on an Adafruit HUZZAH I have:

> 
> print(node.info()) 
2	2	0	1389798	1458400	4096	2	40000000
>

and a reset gives:

NodeMCU 2.2.0.0 build April 2019 powered by Lua 5.1.4 on SDK 2.2.1(6ab97e9)

I've been updating a number of systems, and a more precise indication of
the running NodeMCU version would be helpful. The easiest way would seem
to be the use of the Git checksum, perhaps via 'git log -1 --pretty="%H"'
or "%h"; if a Git server hook were used to write that information to a
project header file, and the result added to the signon, a firmware binary
could be easily identified.

Does GitHub have server hooks available to the project?

Justification

It would make checking and updating firmware easier..

Workarounds

No, but editing the header files directly would be possible.

C W Rose

[HHHartmann]

Maybe we could move the mechanism used in docker to the build system.
This should then append the given message from the header.

[nwf]

I'd prefer that the docker system ultimately move to something else; rewriting the header file is kind of rude and leaves the build tree dirty when the builds fail. The usual dance here is to have make build a file from the output of git describe; something like:

$(shell echo 'static const char git_rev_bytes[] = { $(shell git rev-parse HEAD | sed -e "s/\(..\)/0x\1,/g") };' >> $(ROOT_DIR)/build-version.h)

A slightly better version of the above generates a temp file and only replaces the build-version.h if the temp file differs from the existing one, so that make's extremely limited change detection logic doesn't cause rebuilds all the way up the dependency tree.

[cwrseck]

@nwf the Makefile might well be a better approach; I did something similar with Mercurial and an (Autotools) makefile. Given a separate version.h, updated only on success, excessive rebuilds should be avoidable.

C W Rose

[marcelstoer]

This is more or less a dup of #2398

I'd prefer that the docker system ultimately move to something else; rewriting the header file is kind of rude and leaves the build tree dirty when the builds fail.

👍fully agree

However, it's also true that both the cloud builder and the Docker builder have the need (says I) to inject extra information beyond the Git revision. So if our build could offer a hook for that I'd be more than happy to remove the work around. How about including an optional additional file like auxiliary-build-version.h that external build tools could create and populate?

[cwrseck]

Yes, this looks like a re-run of #2398. I don't know enough about the build system to provide a solution, but if it's simple it would be well worth doing. (I don't really understand the 2.2.0 from node.info(), either.)

C W Rose

[HHHartmann]

Maybe we could agree to add even more information, as requested in #1739 to the signeon and node.info() effectively moving the functionality from the docker build into the main build.
Have a file buildinfo.h generated on build and include it in user_version.h. So if a user wants to customize the signon message she still can.
buildinfo.h would not get checked in and only overwritten when different.

[marcelstoer]

The problem with fiddling with *.h files is that make will/might build everything from scratch with each invocation (rather than just the changes). marcelstoer/docker-nodemcu-build#64 is still open.

[HHHartmann]

including the file in user_version.h just triggers rebuild of lua/lua.c and node.c.
Haven't tried esp32 though.

[HHHartmann]

@marcelstoer I just tried git tag -l --points-at HEAD on current master, which yielded an empty output because there was on commit after the release.
Shozuld we instead use git describe --tags and parse the result in TAG and +n commits?

It also might make sense to add a dirty indication. But the it would always be dirty on an individual build (selecting modules). How to handle this?

[nwf]

Resolved by #2830.