Follow-up items: ch -v and --version

[dilijev]

Follow-up from issue #109
Initial implementation merged into release/1.4 in time for v1.4.1. (PR #2490)
See also issue #2472

Follow-Up Work Items

(Will be followed-up in master.)

• Error checking/reporting: "ch -v" doesn't complain even if chakracore cannot be loaded? #2617
• Windows Official Builds: Additionally report branch, hash, build number, build date.
  • Trivially, this could be the file description directly: release/1.4:6b404ca7761420ec8634ce7888c6fd2ca1ed01f5.00009.64404.161220-2254 which is <branch>:<hash>.<buildID-part1>.<buildID-part2>.<build-date>. The output would look like Listing 1.
  • Alternately, could take that info and parse it into a clearer format like Listing 2.
• Dev (Private) Builds on Windows: Report that it is a dev build by adding -dev or -private suffix to build number (e.g. 2.0.0.0-dev). Much of the official build metadata would be missing, see Listing 3.
• Xplat Builds (cc @obastemur -- what do you think?)
  • Embed information in the binary that can be read in a way like how we read it from ChakraCore.dll on Windows. Most likely needs cmake modification.
  • Implement reading this information to report version info for xplat binaries.

Listing 1 (official builds -- proposed output -- short variant):

ch.exe version 1.4.1.0
release/1.4:6b404ca7761420ec8634ce7888c6fd2ca1ed01f5.00009.64404.161220-2254

chakracore.dll version 1.4.1.0
release/1.4:6b404ca7761420ec8634ce7888c6fd2ca1ed01f5.00009.64404.161220-2254

Listing 2 (official builds -- proposed output -- verbose variant):

ch.exe version 1.4.1.0 release/1.4@6b404ca7
Branch: release/1.4
Hash: 6b404ca7761420ec8634ce7888c6fd2ca1ed01f5
Build Number: 00009.64404
Build Date: 161220-2254

chakracore.dll version 1.4.1.0 release/1.4@6b404ca7
Branch: release/1.4
Hash: 6b404ca7761420ec8634ce7888c6fd2ca1ed01f5
Build Number: 00009.64404
Build Date: 161220-2254

Listing 3 (dev builds -- proposed):

ch.exe version 1.4.1.0-dev
chakracore.dll version 1.4.1.0-dev

/cc @tcare @curtisman @obastemur @bterlson @mathiasbynens

[obastemur]

Xplat Builds (cc @obastemur -- what do you think?)

    Embed information in the binary that can be read in a way like how we read it from ChakraCore.dll on Windows. Most likely needs cmake modification.
    Implement reading this information to report version info for xplat binaries.

@dilijev I'm not sure why we need this? Don't we also ship version header file along with the package? Besides, apart from providing a runtime interface, IIRC .so file doesn't have a dll/dylib like package features.

[dilijev]

why we need this?

For the distinction between ch version and ChakraCore version. It would be good to have ch read the actual version from the ChakraCore library.

[Penguinwizzard]

@obastemur: We could just drop a .note.chakra or .note.buildinfo section into the output elf file with all that version information. It's not standardized, but that'd be the place to put it.

[obastemur]

@obastemur: We could just drop a .note.chakra or .note.buildinfo section into the output elf file with all that version information. It's not standardized, but that'd be the place to put it.

@Penguinwizzard node.buildinfo IIRC is used for compiler version and tend to be discarded.

I might be missing the point here. Let me try again; we provide ChakraCoreVersion.h and embedder knows the version of ChakraCore static/shared lib.

For the distinction between ch version and ChakraCore version. It would be good to have ch read the actual version from the ChakraCore library.

@dilijev why ch doesn't read the actual ChakraCore version from that header file ?

If it is about the version of ch file, ch -? should suffice.

[ThomsonTan]

why ch doesn't read the actual ChakraCore version from that header file ?

@obastemur, Probably because we could use ch to load to ChakraCore in slightly different version if compatible?

@dilijev for dev builds, beyond static information for the source code, I think put some environment information like build machine name or current user name would be helpful, because private version hash doesn't make a lot of sense.

[dilijev]

@obastemur: @ThomsonTan has the idea right. On Windows, we don't statically link ChakraCore into ch and ch will try to load the ChakraCore.dll in the same dir. See listings in this comment: #2490 (comment)

If the version of ch exactly matches the version of ChakraCore, there's no problem. In most cases this is how ChakraCore+ch will be used together. In any case, we report both versions.