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.)
Related
I would like to edit an existing software to add a new source file (Source.cpp).
But, I can't manage the compilation process (it seems to be automake and it looks very complicated).
The software (iperf 2: https://sourceforge.net/projects/iperf2/files/?source=navbar) is compiled using a classical ./configure make then make install.
If I just add the file to the corresponding source and include directory, I got this error message:
Settings.cpp:(.text+0x969) : undefined reference to ...
It looks like the makefile isn't able to produce the output file associated with my new source file (Source.cpp). So, I probably need to indicate it manually somewhere.
I searched a bit in the project files and it seemed that the file to edit was: "Makefile.am".
I added my source to the variable iperf_SOURCES in that file but it didn't workded.
Could you help me to find the file where I need to indicate my new source file (it seems a pretty standard compilation scheme but I never used automake softwares and this one seems very complicated).
Thank you in advance
This project is built with the autotools, as you already figured out.
The makefiles are built by automake. It takes its input in files that usually have a am file name extension.
The iperf program is built by the makefile generated from src/Makefile.am. This is indicated by:
bin_PROGRAMS = iperf
All (actually this is a simplification, but which holds in this case) source files of a to be built binary are in the corresponding name_SOURCES variable, thus in this case iperf_SOURCES. Just add your source file to the end of that list, like so (keeping their formatting):
iperf_SOURCES = \
Client.cpp \
# lines omitted
tcp_window_size.c \
my_new_file.c
Now, to reflect this change in any future generated src/Makefile you need to run automake. This will modify src/Makefile.in, which is a template that is used by config.sub at the end of configure to generate the actual makefile.
Running automake can happen in various ways:
If you already have makefiles that were generated after an configure these should take care of rebuilding themselves. This seems to fail sometimes though!
You could run automake (in the top level directory) by hand. I've never done this, as there is the better solution to...
Run autoreconf --install (possibly add --force to the arguments) in the top level directory. This will regenerate the entire build system, calling all needed programs such as autoheader, autoconf and of course automake. This is my favorite solution.
The later two options require calling configure again, IMO ideally doing an out of source built:
# in top level dir
mkdir build
cd build
../configure # arguments
make # should now also compile and link your new source file
I recently started working with WxWidgets (2.9.4) and was working through a tutorial I found, but it seems that I'm unable to load any images. I've already properly used the handler (for PNG) and the problem happens at run-time. Below is an image of the popup that is displayed when attempting to run the program.
Here is the code:
wxPNGHandler *handler = new wxPNGHandler;
wxImage::AddHandler(handler);
wxBitmap exit;
exit.LoadFile(wxT("exit.png"), wxBITMAP_TYPE_PNG);
wxToolBar *toolbar = CreateToolBar();
toolbar->AddTool(wxID_EXIT, exit, wxT("Exit"));
toolbar->Realize();
Connect(wxID_EXIT, wxEVT_COMMAND_TOOL_CLICKED, wxCommandEventHandler(mainWindow::exitProg));
Any help is appreciated.
EDIT: I forgot to mention that when I click Cancel, this happens:
I placed the exit.png file in the build directory (/Debug or /Release) as well as the source code directory, but it still has yet to see it.
What is your working directory?
If you are using visual studio and running using the interface ( F5 or ctrl-F5 or the little run button in the toolbar ) then your working directory is the folder containing the project file. So try copying your image file there.
Or open a command window, cd to one of your build directories, and run your app from the command line.
In general, to avoid this sort of problem, I alter the project properties so that the executable is NOT stored in one of the build folders, but in a new folder ( which I usually call 'bin' - my unix roots are showing! ) and also alter the debugging properties so that the working directory is the bin folder.
There are a couple of advantages to this technique:
Both the release and trhe debug version use the same folder, so you only need one copy of any extra file, like your image file.
It is easy to see the executable and extra files in the working directory without being distracted by all the .obj files that end up in the build folders
IMHO this is well worth the little extra trouble in maintaining non default project properties.
First of all, to avoid problems deep inside wxToolBar, always check the return code of LoadFile() or, alternatively, use wxBitmap::IsOk() to check that the bitmap was successfully loaded.
Second, while adding the handler explicitly as you did is perfectly fine, I'd recommend to just call wxInitAllImageHandlers() as it's simpler and has no real drawbacks unless you are looking to create the smallest program possible.
Finally, to address your real problem, the file clearly doesn't exist at the path you're loading it from. You can, of course, solve this by being careful not to change your working directly (or restore it after changing it) in your program and by placing the file in the correct place. But this is, as you discovered, error-prone, so a better idea is to always use full paths to your resources. To construct them, you will find wxStandardPaths useful, in particular its GetResourcesDir() method.
I am looking for some documentation or tutorial for copying files from a given directory into the app created by xcode at build time, before it is run.
At first I have tried to copy files into the derived directory, hoping that everything resides in there would be automatically added to the app, but I was wrong.
So I am looking for a script because the original dir may change its name, second the script could be customized by another xcode 4 user with its src dir path etc.
The things is I don't know how to start, which language etc. I am quite confident with shell script, but maybe there's a better option.
Second, I am trying to figure out which command could add a file in the already built app.
thanks
That answer didn't really help - the BUILT_PRODUCT_DIR isn't where most stuff goes.
Ultimately, I found you just need to do:
Add the following to the very end of your script (or get your script to write directly to the output location):
cp ${DERIVED_FILE_DIR}/[YOUR OUTPUT FILES] ${BUILT_PRODUCTS_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}
...but there's a lot of other things I tried. More thoughts and ideas here: http://red-glasses.com/index.php/tutorials/xcode4-a-script-that-creates-adds-files-to-your-project/
You want a Run Script or Copy Files build phase. Select your main project in the navigator, then select the app's target. Click the Build Phases tab. Click the Add Build Phase button at the bottom of the window and choose the appropriate phase.
By "appropriate" I mean if you really want to run a script, you'll use a Run Script build phase and use Xcode-provided environment variables like $BUILT_PRODUCT_DIR (see the documentation or hit build and examine the full output of an empty script in the build log) to figure out your target folder. If all you want to do is copy files (no real processing), the Copy Files build phase already knows how to locate the app bundle's proper folders depending on what you're copying (Resources, Frameworks, etc.).
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.
I am trying out lua script with C++ in Mac OS X. I was finding a way to make the program returning the current working directory. That's no problem with getcwd, but then I came one thing:
My foo.lua stays at its initial path only. When I compile program, it is not being copied over to the build/Debug directory. Sure, I can grab my script there, but that's just impractical. XCode or any IDE should carry resources to the build zone. XCode does this automatically with iPhone app, but this seems to be a different case. For this case, how to command XCode to put the respective resources in the build directories?
int main (int argc, char * const argv[]) {
...
...
luaL_dofile(luaVM,"/Users/yourNameHere/Desktop/LuaSandbox/LetsTryLua/foo.lua");
//typing the whole absolute path here is just ugly and impractical.
...
...
printf("working directory: %s", buffer);
//output is: working directory: /Users/yourNameHere/Desktop/LuaSandbox/LetsTryLua/build/Debug
...
...
Rather than hard code the path to your Lua script you may want to use the NSBundle API's to find it:
NSBundle * mainNSBundle = [NSBundle mainBundle];
NSString * luaFilePath = [mainNSBundle pathForResource:#"foo"
ofType:#"lua"
inDirectory:NULL
forLocalization:NULL];
luaL_dofile(luaVM,[luaFilePath UTF8String]);
This will find it in the bundle's folder (if you added the "Copy Bundle Resources" build step to your target as the above poster suggested.
Because you're using a .lua file as a resource, I suspect that isn't recognised as a standard resource type and hence it hasn't been automatically copied. You should be able to do this though by adding an extra Copy Bundle Resources build step to your target and then add your file to it in the project view.
If you're creating a command line tool that is not a bundle, then there's never going to be a good solution. If you're creating a regular app then the aforementioned solution will work, but you're going to have to stop assuming that your working directory is set to anything even remotely meaningful at any point in time and use the appropriate methods for finding resources stored within your bundle.