Bitcoin-Qt (Windows only): add version info to Resource File #1683

pull Diapolo wants to merge 1 commits into bitcoin:master from Diapolo:Qt_Win_exe_version changing 6 files +39 −16
  1. Diapolo commented at 10:57 PM on August 17, 2012: none

    This extends #1607, which got recently merged, with version information for bitcoin-qt.exe (no additional files need to be modified by hand).

    • add version information to bitcoin-qt.rc, which is displayed on Windows, when looking in the executable properties and selecting "Details"
    • introduce a new clientversion.h (used in bitcoin-qt.rc to generate version information), which takes only the version defines from version.h and is included in it (to allow usage with the windres rc-file compiler)
    • move #define STRINGIFY(s) #s into clientversion.h as that is used in bitcoin-qt.rc and rename to DO_STRINGIZE(X)
    • add #define STRINGIZE(X) DO_STRINGIZE(X), which is needed to convert the version defines into a version string in the rc-file
    • this ensures we only need to update 1 file and have bitcoin-qt.exe version information
    • for RC-file documentation see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058%28v=vs.85%29.aspx

    bitcoin-qt.exe details

  2. BitcoinPullTester commented at 5:11 AM on August 18, 2012: none

    Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/78e748f5feea9a3fcd83ba1a8451c96e67dc4d76 for binaries and test log.

  3. laanwj commented at 9:09 AM on August 18, 2012: member

    NACK until the version is determined automatically from version.h, we don't want to have to manually change the version number in another place for every release.

  4. Diapolo commented at 9:12 AM on August 18, 2012: none

    @laanwj I know that you don't want this like it is now, but for reference and discussion it needs to be here, as I'm unable to do Linux scripts or stuff like that :). That's why I mentioned build.h.

  5. Diapolo commented at 9:58 AM on August 23, 2012: none

    A good new point was raised, which makes valid version information even more valuable. Security-Scanners like Secunia PSI rely on version information to determine if an application is secure or has known and reported security flaws.

  6. sipa commented at 10:11 AM on August 23, 2012: member

    How about using git's export-substitution mechanism, which is also used in version.h, when build.h is unavailable? You could get the commit id, date, and in case of releases, tag name of the latest commit that way.

  7. Diapolo commented at 10:36 AM on August 23, 2012: none

    I "only" need our version information in this format:

    <pre> #define VER_PRODUCTVERSION 0,6,99,0 #define VER_PRODUCTVERSION_STR "0.6.99.0" </pre>

    @sipa Tell me, do you think this is achievable via your suggestion?

  8. sipa commented at 10:51 AM on August 23, 2012: member

    Do you think it's possible to just #include "version.h" in that .rc file? If so, it isn't hard.

  9. Diapolo commented at 10:56 AM on August 23, 2012: none

    I tried that, but the windres resource-file compiler doesn't like code other than a #define, which sucks in that case. If we could seperate out the pure version number stuff, which consists of only #define, into anoter small header, which we then include in version.h and the resource-file ... that could do the job. And we keep that 1 place, where manual changes need to be made.

  10. sipa commented at 11:17 AM on August 23, 2012: member

    So what we can do, using export-subst, is have the unix timestamp as VER_PRODUCTVERSION, and the formatted data as VER_PRODUCTVERSION_STR, with the tag name after it.

    So VER_PRODUCTVERSION would be 1345657778, and VER_PRODUCTVERSION_STR would be "2012-08-22 10:49:38 -0700". When 0.7 is released, " (0.7.0)" could be appended.

  11. Diapolo commented at 11:31 AM on August 23, 2012: none

    I guess I have found a solution, just need to verify it doesn't break version.cpp now :). Just a few minutes...

  12. sipa commented at 11:57 AM on August 23, 2012: member

    Does it build/work now?

  13. Diapolo commented at 12:02 PM on August 23, 2012: none

    It builds without errors (and that's the most important thing), but one of the version parts seems not working, I observed this after I updated the pull ... currently looking into that :-/.

  14. Diapolo commented at 1:16 PM on August 23, 2012: none

    Updated, I needed to add the #define TOSTRING(s) STRINGIFY(s) macro for it to work (see http://www.decompile.com/cpp/faq/file_and_line_error_string.htm for more information) and now it's working like it should :).

  15. BitcoinPullTester commented at 1:57 PM on August 23, 2012: none

    Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/07693fb5f7e8f7eed8355832b07414ff5f06e527 for binaries and test log.

  16. in src/clientversion.h:None in d379680847 outdated 
      10 | +#define CLIENT_VERSION_MINOR       6
  11 | +#define CLIENT_VERSION_REVISION   99
  12 | +#define CLIENT_VERSION_BUILD       0
  13 | +
  14 | +#define STRINGIFY(s) #s
  15 | +#define TOSTRING(s) STRINGIFY(s)
    gavinandresen commented at 2:00 PM on August 23, 2012:

    I like boost's naming convention for this better; see boost/suffix.hpp:

    //
    // Helper macro BOOST_STRINGIZE:
    // Converts the parameter X to a string after macro replacement
    // on X has been performed.
    //
    #define BOOST_STRINGIZE(X) BOOST_DO_STRINGIZE(X) #define BOOST_DO_STRINGIZE(X) #X

    Nice comment, DO implies it is an implementation detail...

    Diapolo commented at 2:22 PM on August 23, 2012:

    I didn't know Boost has such a thing, thanks. Do you suggest to use and include suffix.hpp or just do this?

    <pre> #define STRINGIZE(X) DO_STRINGIZE(X) #define DO_STRINGIZE(X) #X </pre>

    I think the later is nicer, as we don't need the rest of suffix.hpp and it perhaps confuses the windres rc-compiler.

    gavinandresen commented at 4:19 PM on August 23, 2012:

    Just do this. But add a comment so somebody clueless doesn't later decide to 'optimize' the two macros by collapsing them into one.

  17. laanwj commented at 4:38 PM on August 23, 2012: member

    Great to see that this is solved.

  18. Diapolo commented at 4:41 PM on August 23, 2012: none

    Updated to include a comment for the macros, looks good to me. I just don't know how many messages @BitcoinPullTester will create now ;). I would like to take a look at it, after this last update, to be sure.

  19. Diapolo commented at 9:22 AM on August 24, 2012: none

    Come on dear @BitcoinPullTester, I want a build to get this in 0.7 :). Well there is no folder for commit-ID a5266398d88c6e596b91208eca0ce3aee5b5e3cb, so I guess I won't get one ^^.

    Well as I said on Windows everything is looking good, so it should be safe to give it a try before 0.7 RC?

  20. Diapolo commented at 12:14 PM on August 24, 2012: none

    Well, I downloaded bitcoin-qt.exe from http://jenkins.bluematt.me/pull-tester/07693fb5f7e8f7eed8355832b07414ff5f06e527 (last build mentioned above) and looked at the version information ... it's in and looks like the screenshot in the first posting :).

    Edit: Yeah I remember, the last change was just a comment update!

  21. laanwj commented at 3:03 PM on August 24, 2012: member

    BTW, a bit off-topic but what is VERSION in bitcoin-qt.pro used for? I don't see it being passed to anything, and I think it can be removed without hurt now that we have version.h.

    I see it was added by Gavin in 0.5.0: https://github.com/bitcoin/bitcoin/commit/94eaab77109dd4fa568a855a375adb2c2a3207f9

  22. Diapolo commented at 3:24 PM on August 24, 2012: none

    @laanwj I never understood, where the Qt version variable was used. I can do a diff of the makefiles WITH and WITHOUT VERSION and report back.

  23. Diapolo commented at 3:42 PM on August 24, 2012: none

    I checked the makefiles, VERSION is nowhere used in it.

  24. gavinandresen commented at 4:30 PM on August 24, 2012: contributor

    I think (but I'm not sure) that the OSX create-a-dmg-package uses it.

  25. laanwj commented at 8:15 AM on August 26, 2012: member

    Ok, good reason to keep it around.

  26. BitcoinPullTester commented at 9:22 AM on August 26, 2012: none

    Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/a5266398d88c6e596b91208eca0ce3aee5b5e3cb for binaries and test log.

    This could happen for one of several reasons:

    1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts
    2. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
    3. The test suite fails on either Linux i386 or Win32
    4. The block test-cases failed (lookup the first bNN identifier which failed in http://jenkins.bluematt.me/pull-tester/files/FullBlockTestGenerator.java)
  27. Diapolo commented at 10:02 AM on August 26, 2012: none

    It seems the relative path I used in Windows format (in the .rc file) is incompatible with the cross-compilation. I'll update later with Linux style format.

    Edit: I changed #include "..\..\clientversion.h" into #include "../../clientversion.h", which still compiles just fine on Windows. Waiting now for a @BitcoinPullTester confirmation.

  28. laanwj commented at 6:19 AM on August 30, 2012: member

    @thebluematt we could use another pulltester run here :-)

  29. BitcoinPullTester commented at 12:33 PM on August 30, 2012: none

    Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/016649d8b83d0f64a0c1ccfe28719913c18a5e4c for test log.

    This pull does not merge cleanly onto current master

  30. Diapolo commented at 1:04 PM on August 30, 2012: none

    Once more it tried to use an old commit-ID, which isn't there anymore: fatal: '016649d8b83d0f64a0c1ccfe28719913c18a5e4c' does not point to a commit

    So we need to wait a little longer for the most current one I guess ;).

  31. Diapolo commented at 9:23 PM on August 30, 2012: none

    I had to rebase, as another small fix created a merge-conflict...

  32. Diapolo commented at 12:21 PM on September 1, 2012: none

    @TheBlueMatt Any idea, why @BitcoinPullTester refused to build anything for us? I would love to see this in 0.7 final.

  33. TheBlueMatt commented at 5:58 PM on September 1, 2012: member

    Sorry, @Diapolo, pull tester is currently paused pending an upgrade to the block tester. I should have time to get it back up today.

  34. laanwj commented at 6:16 AM on September 5, 2012: member

    It's started testing again, but not here.

  35. Diapolo commented at 6:46 AM on September 5, 2012: none

    @laanwj I rebased to current master to create a new commit-ID, hope that helps.

  36. Diapolo commented at 4:50 PM on September 5, 2012: none

    Rebased to match the 0.7rc2 version information. Still no sign from @BitcoinPullTester :-(. @TheBlueMatt Can you check why this pull seems to be ignored by it?

  37. TheBlueMatt commented at 5:02 PM on September 5, 2012: member

    @Diapolo calm down, this pull is pretty far down the list, there is quite a backlog, and each test takes a number of hours, it may be a few days...

  38. BitcoinPullTester commented at 2:27 PM on September 6, 2012: none

    Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/1d605035f7c7d8b312e4df836acbda958e32f417 for test log.

    This pull does not merge cleanly onto current master

  39. Diapolo commented at 4:52 PM on September 6, 2012: none

    @TheBlueMatt It seems once more a no more existing commit ID was chosen. Any idea for this?

  40. TheBlueMatt commented at 4:57 PM on September 6, 2012: member

    @Diapolo again, the backlog is pretty long, you'll have to wait for it to finish its current run and start the next before it picks up the latest commit id.

  41. BitcoinPullTester commented at 1:42 PM on September 7, 2012: none

    Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/7f7a738814ea67499c415c5a132670b3573aa3dd for binaries and test log.

  42. Bitcoin-Qt (Windows only): add version info to Resource File
    - add version information to bitcoin-qt.rc, which is displayed on Windows, when looking in the executable properties and selecting "Details"
- introduce a new clientversion.h (used in bitcoin-qt.rc to generate
  version information), which takes only the version defines from
  version.h and is included in it (to allow usage with the windres rc-file
  compiler)
- move #define STRINGIFY(s) #s into clientversion.h as that is used in
  bitcoin-qt.rc and rename to DO_STRINGIZE(X)
- add #define STRINGIZE(X) DO_STRINGIZE(X), which is needed to convert the
  version defines into a version string in the rc-file
- this ensures we only need to update 1 file and have bitcoin-qt.exe
  version information

- for RC-file documentation see:
  http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058%28v=vs.85%29.aspx
    f875921176
  43. Diapolo commented at 2:11 PM on September 7, 2012: none

    @laanwj YES, it finally works, I downloaded bitcoin-qt.exe and can verify it works! The last rebase was needed to update to 0.7.0.2 for RC2. @TheBlueMatt Sorry that I was so impatient ^^.

  44. laanwj referenced this in commit 7b1504ccb8 on Sep 7, 2012
  45. laanwj merged this on Sep 7, 2012
  46. laanwj closed this on Sep 7, 2012
  47. suprnurd referenced this in commit 1df889e231 on Dec 5, 2017
  48. DrahtBot locked this on Sep 8, 2021
Contributors
DiapoloBitcoinPullTesterlaanwjsipagavinandresenTheBlueMatt
Linked (view graph)
#1607 Bitcoin-Qt (Windows only): extend Resource File
github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-21 18:16 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me