I'm not sure if this is too general, so if it is I'll say that I'm on Linux using qmake, but I'd like to be able to switch from Linux to Windows with my project whenever I need to, as well as, possibly other PCs.
In order to do this, I'd like to know how some of the programmers on here have gotten around using resource directories without using absolute path definitions. With Qt, it seems like the runtime working directory is the build directory of the application, and not the source directory.
Ideally, I think the best solution would be to somehow get the Resource directory as it resides in the source directory and copy that to the relative build directory (i.e., Debug or Release, depending on development stage) so that the application can access that via run time.
This can introduce some complication, however (at least, I think it can).
Anyway, what would be a good solution to do this?
If you are using Qt. I would suggest using deploy process.
http://doc.qt.digia.com/qtcreator/creator-building-running.html
Basically, you just need to declare which directories need to be copied.
The qt creator will copy those dirs to build dir(release/debug) after build process is done.Then you simply run the executable.
Here is one of example.
https://github.com/longwei/incubator-cordova-qt.
in the pro file
wwwDir.source = www
xmlDir.source = xml
qmlDir.source = qml
DEPLOYMENTFOLDERS = wwwDir xmlDir qmlDir
second
include(deployment.pri)
qtcAddDeployment()
then it is done.
Its not clear what exactly you're trying to achieve, but perhaps a simple solution would be for the build scripts to pass the necessary path via a compilation definition (-D with gcc). Then depending on if its a Debug, Release, etc build, the definition would be set accordingly, then the corresponding binary would have the correct path.
As a side note, I tried qmake for a while, but found SCons to be much more versatile.
Related
My question is the following:
Is there a way to tell CMakeFiles where to generate it's makefiles, such as cmake_install.cmake, CMakeCache.txt etc.?
More specifically, is there a way to set some commands in the CMakeFiles that specifies where to output these generated files? I have tried to search around the web to find some answers, and most people say there's no explicit way of doing this, while others say I might be able to, using custom commands. Sadly, I'm not very strong in cmake, so I couldn't figure this out.
I'm currently using the CLion IDE and there you can specifically set the output path through the settings, but for flexibility reasons I would like as much as possible to be done through the CMakeFiles such that compiling from different computers isn't that big of a hassle.
I would also like to avoid explicitly adding additional command line arguments etc.
I hope someone might have an answer for me, thanks in advance!
You can't (easily) do this and you shouldn't try to do it.
The build tree is CMake's territory. It allows you some tiny amount of customization there (for instance you can specify where the final build artifacts will be placed through the *_OUTPUT_DIRECTORY target properties), but it does not give you any direct control over where intermediate files, like object files or internal make scripts used for bookkeeping are being placed.
This is a feature. You have no idea how all the build systems supported by CMake work internally. Maybe you can move that internal file to a different location in your build process, which is based on Unix Makefiles. But maybe that will also horribly break my build process, which is using Visual Studio. The bottom line is: You shouldn't have to care about this. CMake should take care of it, and by taking some freedom away from you, it ensures that it can actually do that job on all supported build toolchains.
But this might still be an unsatisfactory answer to you. You're the developer, shouldn't you be in full control of the results produced by your build? Of course you should, which is why CMake again grants you full control over what goes into the install tree. That is, whatever ends up in the install directory when you call make install (or whatever is the equivalent of installing in your build toolchain) is again under your control.
So you do control everything that matters: The source tree, the install tree, and that tiny portion of the build tree where the final build artifacts go. The rest of the build tree is off-limits for you and for good reasons.
I'm building a huge C++/Qt project for Android using QtCreator. I have scripts generating .pro files and I'd like to specify within the .pro file that I wish to have the build multi-threaded.
I know I can go to project options and add -j%NUMBER_OF_PROCESSORS% option to Make:
However, as I want to have this option set to all our projects and for every developper, I'd like to have this option be set from the .pro file.
I tried:
QMAKE_CXXFLAGS += -j%NUMBER_OF_PROCESSORS%, but this sets the option to arm-linux-androideabi-g++, whil it should be set to mingw32-make.exe
$$(MAKEFLAGS) = -j%NUMBER_OF_PROCESSORS%, no success...not sure that's the right syntax to set and environment variable from .pro file...not even sure that's doable.
$$(MAKE_COMMAND) = mingw32-make -j%NUMBER_OF_PROCESSORS%, no success
Does anyone know how to set this option from .pro file?
There is no way for the simple reason that it doesn't belong in the project file. What if a developer on your team doesn't want to use all his cores because he's doing something else and he wants a bit more CPU juice at the same time? What if someone has 2 cores less than the number you chose? What if someone has more cores than the number you chose?
In short: don't. If you want optimal cpu core usage, use something like Ninja, which does so automatically, without the need of a specific number.
Note: Ninja won't work with qmake. Try CMake if it's at all possible. Even though the scripting language is terrible, it offers a lot of possibilities and flexibility in return.
Project's build and run settings are saved in .pro.user file, AFAIK. You could modify .pro.user with your script, find a line that looks something like this:
"< value type="QString" key="Qt4ProjectManager.MakeStep.MakeArguments">[EMPTY, OR SOME OTHER MAKE ARGUMENTS]< /value>"(might be slightly different depending on version and platform) and change whatever is in the place of
[EMPTY, OR SOME OTHER MAKE ARGUMENTS] with -j%NUMBER_OF_PROCESSORS%.
However, you would need to preserve most of the other settings in .pro.user file for each particular user meaning that you would need your script to be run on each host, and in a case any of the users changes make arguments in Qt Creator's build settings. Please note that i'm not saying that it is a good idea modifying .pro.user manually, but it is a way of doing what you wanted.
Actually, he best is to recommend every developer that wants to spped-up compilation to set MAKEFLAGS environment variable. It can decide to set it to -j2 or -j4 or -j%NUMBER_OF_PROCESSORS% (if it wants a fast compilation even if it overloads the computer).
This is then used by make and applies to every project compiled with QtCreator. The fact that the option is used is absolutely not visible in QtCreator (nor in the options page, nor in the log), however, you can see in Windows task manager that several instances of g++ are ran in parallel.
I have developed an application that I plan to deploy on Windows, Mac, and Linux. The program requires access to some files (scripts and the like) at run-time.
The installation process should install the files to a location that my application can later determine without user-intervention (or perhaps just a prompt allowing the user to change the location, if desired).
What is the best way to achieve this? I can't seem to find any way to:
1. Use a "standardized path" variable in the project file's INSTALLS statement. (e.g., my application could use QStandardPaths to initialize the location, but I can't figure out how to access this path from the INSTALLS statement)
2. Save the path to my project's QSettings (.plist, registry, whatever) for later retrieval
That leaves me with creating a custom project file and INSTALLS command for each environment, and then I still can't install to the user's directory because I don't know the user's name when I deploy the make command. It seems as if there must be a better way, but I can't seem to find any documentation for this. Am I just using the wrong keywords in my searches? Thanks in advance!
What standard directory? What type of getting that standard directory?
For instance, you can put such thing in your windows branch of .pro file:
win32 {
APPDATA_DIR = $$system(echo %APPDATA%) # should be %LOCALAPPDATA% as requested
message($$APPDATA_DIR)
}
Just unsure of what exact kind of standartized path you are talking about. QStandardPaths knows many. It makes sense to be more concrete to find the correspondence with concrete OS.
Also somewhat relative reply on mine, on how to check the correspondence with certain variable, etc: Qt .pro file - how to add conditioning on OSX version?
Maybe this class will help you
QStandardPaths documentation
But your problem is still little bit unclear for me.
Is it possible to combine the following properties, and if so, how?
Store in our version control system some Visual Studio 2008 native C++ (VCPROJ) project files for the developers in our team that use this IDE.
Allow some of those developers to tweak their projects (e.g. using debug version of third-party libraries instead of the usual ones).
Make sure these modifications are done in files that are not versioned.
In other words, I would like to allow developers to tweak some settings in their projects without risking that these changes are committed.
An 'optional VSPROP' file approach seems doomed to fail, as VS2008 refuses to load projects that refer to non-existent VSPROP files...
Any other suggestion? Is this possible with VS2010?
You may not be able to do this but using a solution that generates the vcproj like CMake for example would let you do this. Scripts all your project with CMake and literally conditionally include a config file(if present for example) that developers can change on their setup.
Branches could solve this problem: you create a branch, play with different versions of third-party, merge changes to trunk if results are good.
Well, as a preliminary solution you could put the project file into something like .hgignore or .gitignore after its initial commit.
This way changes to it can't be done accidentally.
At least that's how I handle .hgignore itself.
We use a versionned "common_configuration" folder, and a script which copies project files from this "common_configuration" folder towards the "project" folder.
We have another script to copy the configuration backwards, so the developpers need to make a conscious action to commit their local changes to the global version control system.
It answers partly your needs :
The upside : we have a way to keep a common configuration for everyone, and no accidental committing of local configuration
The downside : blindly copying the files actually crushes local changes. We live with it. We could write some more clever merger tool (using diff, or xml specific manipulations), but don't want to spend to much time on supporting the deployment tools.
I'm writing a program for Linux in C++, and I need to store some additional data, such as images. Stuff like that is usually in /usr/share on Linux.
The user can decide where to install the software (I'm using CMake), thus I should either use /usr/share, /usr/local/share, /home/theuser/somefolder/share or whatever, depending on where he installed it.
I usually go about doing this by figuring out the absolute path to my binary, cutting the trailing "bin" from the path and replacing it with "share". However, this is quite cumbersome and not the least elegant, so I was wondering how other people did it. I'm using boost, but I can't find any respective functions.
I only need the share directory for this project, but I'd also be interested in how you do this with the etc directory (my approach doesn't quite work there, because the binary can be in /usr/bin while the configuration files are in /etc)
The build system should pass the desired install location as a define during the build process. So
gcc -DDATA_DIR=/custom/build/location ...
This means that the install location can't be changed after the code is built, but is the only way to be certain that the code knows where to look, without reading that information somewhere at runtime.
You could use default directories paths.