I would like to have a variable (or #define) in C++ source that will increment each time I use Qt Creator to build source code. Is there any way I can do this, perhaps some Qt Creator plugin or similar? If there is a way to do it if I use "make" on command line to build?
In your .pro file, you can create a variable that contains the results of a command-line program. You can then use that to create a define.
BUILDNO = $$(command_to_get_the_build_number)
DEFINES += BUILD=$${BUILDNO}
If you just want a simple incrementing number, you could use a pretty simple script:
#!/bin/bash
number=`cat build_number`
let number += 1
echo "$number" | tee build_number #<-- output and save the number back to file
I should note that this would cause the build number to increment every time you build, and also increment if you try to build but it fails. A better way is to get a build number based on the state of the code, and many version control tools can get you a text string for that, if not a number.
The Windows equivalent for Joerg Beutel's improved solution https://stackoverflow.com/a/5967447/1619432:
.pro:
build_nr.commands = build_inc.bat
build_nr.depends = FORCE
QMAKE_EXTRA_TARGETS += build_nr
PRE_TARGETDEPS += build_nr
HEADERS += build.h
build_inc.bat:
#echo off
set /p var= <build.txt
set /a var= %var%+1
echo %var% >build.txt
echo #define BUILD %var% >build.h
echo %var%
Usage
#include "build.h"
...
qDebug() << "Build number:" << BUILD;
As I wrote before after some testing I found that the original solution has a problem since the version number is not updated every time a new build is done. In a lot of cases I had edited a source file, run the build, but still got the same build number ... The building process just decided that nothing was changed and skipped the step which would have updated the build number. I first attempted to find a way to force that step, but couldn't figure it out. Finally I decided to go a different way. Now I use the script to generate a header file
build_number.h which contains a #define BUILD with the updated number behind. So Calebs script is now a bit modified (build_number.sh) :
#!/bin/bash
number=`cat build_number`
let number++
echo "$number" | tee build_number #<-- output and save the number back to file
echo "#define BUILD ""$number" | tee ../MyProject/build_number.h
The incrementing number is still stored within a file called build_number. I could have avoided a third file by parsing the generated header-file for the number, but decided against it. Note that the script and the generated header are located in the projects directory while the build_number file is in the build directory. That's not perfect, but I can live with it.
In order to put things together there are now some more things to do. First the generated header-file needs to be added to the project in the Qt Designer ... Right-click on Header-Files and "Add existing file". Second, it has to be included in the C++-file where the BUILD define inside is accessed ... #include "build_number.h" ... and last but not least some additions have to be made to the project file (MyProject.pro). Note that I deleted the stuff from Calebs solution, so we start from scratch here :
build_nr.commands = ../MyProject/build_number.sh
build_nr.depends = FORCE
QMAKE_EXTRA_TARGETS += build_nr
PRE_TARGETDEPS += build_nr
These lines (I put them before the HEADERS section) force the execution of the script, which reads the last build number from build_number, increments it, writes it back and also generates an updated version of the build_number.h file. Since that's part of the source of the project the new value gets linked into the code every time.
There's one thing to mention - now the building process is never at the opinion that nothing has changed. So even if you leave your code unchanged a new run of make will generate a new version number and build a new binary. The old solution left the number when code changed, this new solution forces a new build even when the source is unchanged, since I force a change in that one header file. One would have prefered something in between but since the header is only included in one place the rebuild is very fast and doesn't hurt much. But still, if somebody knows how to get the best of both worlds please advise. At least now I'll not have two different binaries with the same version number.
Caleb's suggestion is great, but didn't work "out of the box" in my case. I got some errors instead and it took some reading to fix them. The changes are very minor. I was using Qt 4.7 on Ubuntu Linux ... The first change, if you can believe it, was in the shell script to go from let number += 1 to let number++ ... I normally use/program Windoze, so I can't explain that, but when I run the script from a command line (shell prompt) in the original case I get errors reported, in the changed case all goes well and incrementing numbers are returned ...
Since it's not completely reported by Caleb - I used build_number.sh as the name of the shell script and made another file with the name build_number (without .sh) and put just a zero inside, nothing else.
The last and most obnoxious bug was fixed by replacing BUILDNO = $$(command_to_get_the_build_number) with BUILDNO = $$system(./build_number.sh) in the Qt project file. Note the system after $$ and the required ./ in front of the file name. The later is elementary for a regular Linux user, but not as much so for a Windows user.
Hope this makes it more straight forward for people new to all this, like myself. You can read more in the Qt Designer Help section if you seek for qmake, including the function reference, Advanced Use etc.
Oh, one last word ... I also had to change DEFINES += -DBUILD=$${BUILDNO} to DEFINES += BUILD=$${BUILDNO}, so the -D is gone. Inside your C++ code you would use BUILD as if you had written #define BUILD 1234 at the top of your file.
Here's a solution for Win7 I came up with based on handle's solution.
This solution also makes Windows give yer version # when you right-click yer target, and choose Properties | Details. It works in Win7, and probably most earlier versions.
Ok, you make yer build_inc.bat:
#echo off
copy /b myapp.rc +,,
set /p var= <build.txt
set /a var= %var%+1
echo %var% >build.txt
echo #define BUILD %var% >build.h
and put it in yer proj folder. (copy /b myapp.rc +,, is inscrutable Microsoft-eese for "touch" - to update a file's time-stamp.) So far, so good - so what?!!
This part is optional, if you don't need the version encoded into the binary. Create a .rc file, e.g.:
#include "build.h"
1 VERSIONINFO
FILEFLAGS 32
FILEVERSION 1, 0, BUILD, 0
PRODUCTVERSION 1, 0, BUILD, 0
FILEOS 4
FILETYPE 1
{
BLOCK "StringFileInfo"
{
BLOCK "040904B0"
{
VALUE "FileDescription", "program"
VALUE "OriginalFilename", "program.exe"
VALUE "CompanyName", "you"
VALUE "FileVersion", "Release"
VALUE "LegalCopyright", "Copyright (c) 2016, you, fool!"
VALUE "ProductName", "Yer proggie"
VALUE "ProductVersion", "Release"
}
}
BLOCK "VarFileInfo"
{
VALUE "Translation", 0x0409, 0x04B0
}
}
A more full-blown version is available here: Versioning DLLs. BTW: It won't work without the VarFileInfo block. This .rc is used for stuff like right-clicking and getting this info in Properties | Details. I have both a M$ .rc file for this info and the app icon, and add other resources in Qt Creator under Resources.
Not so optional: Here's the part I've spent some time hacking to find. In Qt Creator, with yer proj opened, click the little computer icon and put it in release mode. Click on "Projects". Click on "Add Build Step", choose Custom Process Step, and click the hat icon "^" until it is at the top of the list. Say you've named yer .rc, "myapp.rc". Make tha build step read as follows:
Command: cmd.exe
Arguments:/c build_inc.bat
Working Directory: %{CurrentProject:Path}
While a qmake-based version might work well from the command line or command line tools called from an IDE, in Qt Creator, the build steps are preferable, I believe. Qt Creator doesn't actually run qmake for each build; but build steps are run every build.
Now, add this to yer .pro file:
RC_FILE += myapp.rc
Also, add myapp.rc to yer proj. It'll show up under "Other Files".
Now rebuild. Every rebuild will trigger a touch of the resource file, thereby running "rc" every time. Otherwise, the build number won't get encoded into the binary right. It runs quickly for me. Every rebuild will increment this number. I've only bothered to add them to the "Release" build; so debug builds don't increment this. They'll just use the number of the last build. You will need to run it once in release to avoid an error, I believe. This works without separately re-running qmake each time in Qt Creator; and gives you a different build number each time. It doesn't trigger any other recompiles. You have the overhead of running "rc" and linking each time, as opposed to doing nothing if everything is up to date; but OTOH, I do it for release builds only; you almost always link for a build or run anyway; and again, "rc" is fast.
Optional: You can move the BUILD preprocessor symbol wherever you want in yer vers. #. (Note: You can also add yer app icon with something like this:
IDI_ICON1 ICON DISCARDABLE "Icons/myicon.ico"
This makes it show up in Explorer even before the file is run.)
You can also add "build.h" to yer proj formally in Qt Creator, include it in a file you want to use the build # in, and use it as a string, e.g. with:
#include <QDebug>
#include "build.h"
#define STR_EXPAND(tok) #tok
#define STR(tok) STR_EXPAND(tok)
qDebug() << QString("(build ")+STR(BUILD)+")";
I just noticed a side effect: If you do it this way, it will rebuild before every run in Release. I guess that's not too bad a price to pay. I guess I can always copy the runtimes into the release directory, and run it from Explorer; or just put up with the extra compile of my about.h, the run of "rc" and the link with each run in release. For that matter, I could just create an external tool to run it with a keyboard shortcut. I'm certainly open to any improvements on this. For the time being, I'm not bothering, as just compiling "about.cpp", running "rc" and linking with every run doesn't take very long. Still, people: automatic build numbers!
☮!
Edit: Optional: In order to get it to increment the build number only when you build or rebuild your project, but not when you run it (even though a build will always occur in Release), go to Projects | Build and Run | Run, click "Add a Deploy Step" and choose "Custom Process Step":
Command: cmd.exe
Arguments: /c if exist build.old copy /y build.old build.txt
Working Directory: %{CurrentProject:Path}
Then, add
copy /y build.txt build.old
after #echo off in the .bat file. It is even possible, although involved, to make custom new project templates: Extending Qt Creator Manual
Edit: I've now made it work with one, not two, custom build steps.
Related
In one cpp-file I use the __DATE__ macro to get the compile-date.
It gives me the date of the last compile of that file. But as the file is not changed very often, the date is old in most cases, sometimes several months.
What I actually want is the date of the last build of the project.
Is there an setting to force VS2010 to rebuild that single cpp-file on every compile of the project?
Regardless of changes in the file?
The only way I found until now is to modify the file or delete the created obj-file by an script before the build, I would prefer an solution inside VS if that is possible.
You could probably add a Pre-Build Step that touch (see this thread) the file?
To add a Pre-Build Step, open your Project Properties, then Configuration Properties > Build Events > Pre-Build Event then add the command line you want to have executed in Command Line.
Following the suggestion from Amitd, apparently you can also touch the file using PowerShell, see this for explanations.
As suggested by Adrian McCarthy in the comments below, deleting the .obj file would be preferable in the context where source control is used and you want to keep the .cpp read-only. Using the "macros" exposed by Visual Studio, deleting them can be made easy:
del $(TargetDir)sourcefile.obj
Quoted from Cheers and hth. - Alf as another way to achieve this
nmake (bundled with Visual Studio and the SDK) option /t does a touch, it was once the conventional way to do this for Windows programmers.
You can add the following pre-build step, were you simply touch the date stamp of the file. The +,, is a special flag to the copy command, telling it to update the timestamp of the file:
copy file.cpp +,,
As suggested by Adrian McCarthy, you can simply delete the object file every time you build the project.
Therefore, create a pre-build event invoking the del command. According to Microsoft, you can use the $(IntDir) macro to refer to the directory wher the object file is stored (you should not use the $(TargetDir) macro).
I had issues with the return code of the command (error MSB3073), therefore I changed the command to always exit with 0.
del $(IntDir)datefile.obj & exit 0
Create this build event in the project configuration, under Configuration Properties / Build Events.
I have included a unix timestamp __DATE__ in one of my cpp source files to indicate the build date of my program. Naturally with default setups it compiles the file only when I change it but now I'd like to have it always compiled. I tried to search through the project settings but it seems that this would need deeper understanding of the compiler. I'm using Eclipse with g++.
I tried to google and search for an answer but I found it difficult to find good keywords for this.
Also is there a markable difference wether I do this change for a header file instead of the source file?
Thanks for the answers.
You may create a 'pre-build' step which touch the file (so the time stamp is modified and force to recompile the file).
it seems that this would need deeper understanding of the compiler.
No, it must be done by the build system.
A very simple-minded way of doing it is as follows. Create a single file called date.cpp with the following content and nothing else:
#include <string>
std::string build_time() {
return __DATE__ " " __TIME__;
}
You can use it like this in some other source file
cout << "Built on " << build_time() << endl;
The build system keeps track of your changes and it will only recompile those source files that have changed (that are necessary to be recompiled). Since you are not changing date.cpp file, it won't recompile it. However, you can force it by right clicking on the project folder and then
Properties > C/C++ Build > Settings > Build Steps > Post-build steps
and adding the following line to the comand field on Linux:
rm -f <path to the Debug / Release directory>/date.o
where you put yours to <path to the Debug / Release directory>.
On Windows del /q seems to do the same as rm -f, please check.
Since we delete the generated object file date.o, the build system must rebuild it again with the current build date and time when you compile the your application.
It's likely that there are many other variants but the above is in my opinion simple enough and does the trick.
Having a bit of trouble - I've added the following lines to qmake in order to get it to copy files into the app bundle on Mac.
mac {
QMAKE_POST_LINK = $$PWD/package_mac.sh
}
The .sh file runs sometimes, and seems to work (at the moment it just runs touch geese which creates a file named geese in the build directory (excellent!).
But, it doesn't run every time I build, it seems to be only when files are changed. Really, I want a way to get qmake to copy over all my game's resources into the correct places on each platform (so build folder on Windows, app package on Mac, etc...) every time I build.
Any ideas?
Have you tried using POST_TARGETDEPS (with QMAKE_EXTRA_TARGETS)? The downside to this approach is that you'll have to create some sort of dummy file (since to the best of my knowledge .PHONY isn't supported by qmake), which you should probably also clean later.
Taking your example:
mac {
package-script = $$PWD/package_mac.sh
}
package-target.target = $$PWD/package.tmp
package-target.depends = FORCE
package-target.commands = $$package-script
(See this question for a similar discussion.)
In one cpp-file I use the __DATE__ macro to get the compile-date.
It gives me the date of the last compile of that file. But as the file is not changed very often, the date is old in most cases, sometimes several months.
What I actually want is the date of the last build of the project.
Is there an setting to force VS2010 to rebuild that single cpp-file on every compile of the project?
Regardless of changes in the file?
The only way I found until now is to modify the file or delete the created obj-file by an script before the build, I would prefer an solution inside VS if that is possible.
You could probably add a Pre-Build Step that touch (see this thread) the file?
To add a Pre-Build Step, open your Project Properties, then Configuration Properties > Build Events > Pre-Build Event then add the command line you want to have executed in Command Line.
Following the suggestion from Amitd, apparently you can also touch the file using PowerShell, see this for explanations.
As suggested by Adrian McCarthy in the comments below, deleting the .obj file would be preferable in the context where source control is used and you want to keep the .cpp read-only. Using the "macros" exposed by Visual Studio, deleting them can be made easy:
del $(TargetDir)sourcefile.obj
Quoted from Cheers and hth. - Alf as another way to achieve this
nmake (bundled with Visual Studio and the SDK) option /t does a touch, it was once the conventional way to do this for Windows programmers.
You can add the following pre-build step, were you simply touch the date stamp of the file. The +,, is a special flag to the copy command, telling it to update the timestamp of the file:
copy file.cpp +,,
As suggested by Adrian McCarthy, you can simply delete the object file every time you build the project.
Therefore, create a pre-build event invoking the del command. According to Microsoft, you can use the $(IntDir) macro to refer to the directory wher the object file is stored (you should not use the $(TargetDir) macro).
I had issues with the return code of the command (error MSB3073), therefore I changed the command to always exit with 0.
del $(IntDir)datefile.obj & exit 0
Create this build event in the project configuration, under Configuration Properties / Build Events.
There has been confusion a few times with my testers somehow getting old builds of my project to test, and then reporting on fixed bugs.
How can I embed a build ID into my project? Current time of build, or simply starting at 1 and incrementing every time the program is built would work. Then in the game UI, the build number will be printed so there is no ambiguity as to which version of the software the tester is using.
I've googled around for an answer and asked on IRC, but everything I've found seems to pertain only to C#.
Any ideas? On Unix, I would just modify the Makefile, and have some oneliner insert the value I need into the source.
Right now my best idea is to figure out how the VS build process works, then write a python script to run first and edit the source to update the build number.
Ok, here is my quick and dirty and ugly solution.
I have a buildid.txt file, this is a text file with only an integer value for buildid.
I have increment-buildid.bat
#echo off
for /f %%a in (buildid.txt) do (
echo %%a
set /a num=%%a
)
echo %num%
set /a num += 1
echo %num% > buildid.txt
echo int buildid = %num%; > buildid.c
To muck about with the Visual Studio build process, right click solution in solution explorer, -> properties -> Build Events -> Pre-Build Events.
Now that I know how do do this, I can put in my zip + scp script in post build events for instant upload! (not sure of that's blocking or not, will have to test it)
edit: the upload is indeed blocking. that is, debugging does not start until the upload has finished. I just have another batch to upload using scp as I feel the need to. Double click it, and it is sent to remote server.
To solve the same problem, I wrote a small utility that generates a header file containing a date/time stamp in a #define. It runs as a pre-build step and the main project includes the generated header. Then you can include the stamp in a sign-on banner or the like.
In my projects I also generate a version resource, then move it into an .rc2 file (manually written resources) and modify it to include the generated header and update the version appropriately.