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.
Related
UPDATE: I am now able to compile the .cpp file with make
(I can see the compilation output). However, the changes does not seem to take affect.
After i run make, i restart the computer, but still no changes.
As you probably understand, I have very limited experience with c++.
I am currently working on a project (OpenBTS) and have found an error in one of the .cpp files after the project has been built and installed.
My question is, how can I modify the contents (f.eks change the string of a JSON data reference) of a .cpp file and build it so I can see the changes afterwards?
I have currently tried the following:
1.
make 'filename.cpp'
make: Nothing to be done for 'filename.cpp'
2.
make 'filename'
g++ 'filename.cpp' -o 'filename'
In file included from 'filename.cpp:29:0:
'filname.h':26:21: fatal error: Timeval.h: No such file or directory
#include <Timeval.h>
compilation terminated.
3. Run make from root directory:
Nothing to be done for 'all.'
4. Run make clean and make from root. This rebuilds the project but the
changes are still not in effect (I can see that the JSON String is not
changed at the webserver).
5. Run ./build.sh script. Still no changes.
Regarding the 2. method, as the project was built and compiled successfully, how come when i try that with a single file, the compiler can't find the header files? The only thing i changed was a string from "ARFCN" to "ARFCNtest".
Since there are about 50 header files that depends on each other, changing the include from <> to "" and copy every single file into the same directory seems like a waste and unnecessary action?
The changes didn't take effect because the compilation failed. See the error message you quoted in the question. Fix that and rebuild.
Incidentally, restarting your computer shouldn't be necessary. Even the make clean shouldn't be necessary if the Makefile correctly expresses the dependencies. (It seems to do so in this case since it tried to recompile the source file you modified.)
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've been using windows in a class I've been taking but I am trying to run a basic code to figure out how to open/close/input/output from files on Xcode and the code I usually use on visual studios isn't working any idea why? thanks!
#include <string>
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
ifstream fin;
ofstream fout;
string input;
fin.open("inputFile.txt");
if(fin.fail())
cout << "File failed to open." << endl;
fin >> input;
fout.open("outputFile.txt");
fout << input;
}
Put your .txt files in the same directory where your main.cpp file is (or anywhere you like).
In Xcode go to Product > Scheme > Edit Scheme > Run (on the left) > Options (middle top)
Down under Options for "Working Directory" check “Use custom working directory” and set it to the directory where you .txt files are located.
To work with the files, you will have to specify just file names, e.g. in_file.open("inputFile.txt"); no path is necessary.
Here's a completely different approach: Have Xcode copy the input file for you.
Select your project in Xcode
Select Build Phases
Click the '+' button to create a new Build Phase
Select New Copy Files Build Phase
Select Products Directory
Click the '+' button to add your file
Click Add Other
Select your input file and click Open
Check the Copy items… checkbox and click Finish
Now every time you build your project, the input file will be copied to the same folder as the executable no matter where it is built. Of course, to see the output file, you'll still need to find the executable in Finder.
The answers don't really explain the problem so I thought I'd do that.
When you pass a relative path like "inputFile.txt" to file APIs, it's treated as relative to the working directory when the program is executed. This is the same as the 'working directory' when you use cmd.exe or Terminal.app or command lines in general. The Unix command pwd ("print working directory") displays the current working directory. On Windows running the command cd with no arguments performs the same function. (On Unix running cd with no arguments will change the working directory to the user's home directory.)
When you run a program from the command line, the command line shell sets the program's working directory. When you run a program from within an IDE, the IDE sets the working directory. Since, unlike on a command line, there's no obvious answer for what the IDE should set as the working directory, Visual Studio and Xcode set the working directory to different locations by default: Visual Studio sets the working directory to $(ProjectDir), the directory containing the Visual Studio project file; Xcode sets the working directory to the build products directory, i.e. the location the executable was written to.
Some possible solutions to your problem are:
Do not use a relative path, and therefore don't depend on the working directory. This isn't much help in making the program more portable, because the absolute paths will also differ between platforms, and so you will still have to 'configure' the program for each platform. In fact using an absolute path is worse, because it means your source code must differ, whereas it would be better to keep that difference confined to each platform's build configuration.
Configure the IDE to use your desired working directory. Visual Studio can be configured by right clicking the project, selecting Configuration Properties > Debugging > Working Directory, and setting the working directory to the desired path (potentially using Visual Studio build variables).
nepete's answer describes how to configure the working directly set by Xcode.
Configure the IDE's build process to copy your data files to an appropriate location. In Visual Studio you would do this in a C++ project by configuring the project's Properties > Configuration Properties > Build Events.
SSteve's answer covers how to configure additional build steps in Xcode.
I'm guessing you have inputFile.txt in the folder that contains your source code. That's not going to work. You need to put it in the folder that contains the generated executable. To find that folder, right-click on your app under Products and select Show In Finder.
This image shows what it looks like for a command line program. It also shows the Finder window that was opened. As you can see, it is a different folder than the one containing the source code.
As suggested by nepete, edit the scheme, but use $PROJECT_DIR as the custom working directory. Helps with moving the project around, or working in two different environments (e.g., home and office).
BTW. $PROJECT_DIR is one of the Xcode Environment Variables, and also helps with passing file names as command line arguments to programs (settable under "Arguments" in the scheme).
I've struggled with the same problem today. I wanted to add C code to my Swift project and my file pointer was always NULL.
Unfortunately, in XCode 9 for iOS app, I couldn't change the working directory. Changing Build phases didn't help me either. After 4+ hours of trial and error, that's what I've come up with finally and it works:
when copying files to XCode, I've chosen "Create groups", but I needed to choose "Create folder references":
I created a new objective-c file (.m) and copied all my C code there.
I left untouched .h files (XCode generated bridging header and my own .h file with public functions declaration). Now my project structure looked like this:
In my dict.m file in place of previous plain c fopen part:
FILE *dic = fopen("dictionary.txt", "r");
I added obj-C code:
NSString *filePath = [[NSBundle mainBundle] pathForResource:#"dictionary" ofType:#"txt"];
FILE *dic = fopen([filePath cStringUsingEncoding: NSUTF8StringEncoding], "r");
And it works now without any problem! It's just amazing!
ps I decided to write this answer in case it will help someone like me and will save them some time. If you know how to change working directory in XCode 9 for iOS, please, leave me a comment - now I am really curious why I can't find it.
Is there a way to force Visual studio to rebuild a specific file on every build?
I have a version header with __DATE__ and __TIME__ and I want it automatically updated for each release.
I can do a prebuild event and a batch file to touch the file, just wondered if there was a feature to do this yet?
You can also delete the .obj file with a pre-build step. It will cause the compiler to rebuild your .cpp or .h file. Right click your project > Properties > Build events > Pre-Build Event > Command Line and add the following line:
del $(TargetDir)source.obj
From superuser, try adding a prebuild command:
copy /b filename.ext +,,
Where filename.ext is the path/name of the header you want touched. Caveat: I'm not certain VStudio always executes prebuild events, or only if it detects it actually needs to do a build.
There is a touch ms build task. Add it to the build depends on target. http://msdn.microsoft.com/en-us/library/37fwbyt5.aspx
I recently had this question using with the exact same underlying reason of wanting to always update __DATE__ and __TIME__ macros on build. No single answer here worked for me, but they were a great help.
As #Martin-Beckett mentioned in a comment, even pre build events won't run if nothing is perceived as having changed. The key is adding a post event to modify the file of interest. Then every time you hit Build it will be guaranteed to recompile that file as it will have changed after the last compilation.
Both the del $(IntDir)file.obj and copy /b file.h +,, methods worked for me. I'm partial to the copy, so for a step-by-step process:
Right-click project -> Properties -> Build Events -> Post-Build Event > Command Line and add the following line:
copy /b file.h +,,
I would recommend adding a Description for this as it comes up in the Build Output window. Now I can hit Build ten times in a row and that file is recompiled every time.
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.