Crossplatform .pro.user project file
-
I share the same project folder between win/mac (I don't use a version sync system). So I guess I would still have to delete/regenerate to .user each time I switch platform. Unless there's a way to have several .user files at the same time ? Like .user.mac / .user.win
-
You should really, really, really use a version control system. Going without one is a bit like walking the tightrope without a net.
Use one of the distributed ones if you do not care to set up a server...
-
Actually I zip the project every 2 days with a short description, this is my own oldschool version control system.. Though I know it's not as workflow efficient as a real version control system.
So finally I ended up with a .mac.pro / .win.pro file, so I get 2 different .user files generated.
-
You will shoot yourself in the foot some day - be warned! Everyone doing it this way ended up with destroying a whole day's work by extracting the ZIP in the wrong place...
Setting up "mercurial":http://mercurial.selenic.com is so easy that it's not worth fiddling around with ZIP files any more.
-
I am not sure if it is appropriate to re-open this old post, but it is the closest match to what I am looking for...
Basically I have SVN with my windows project on it.
Then to port it to linux I took a branch copy and put it on my linux box. This complained and told me not to use the comfiguration from SVN (rightly so) and so I let QT setup its own config.
So far so good... after a few minor tweaks the project was working nicely on my linux box.
But now I want to have one SVN project that supports both linux and windows whereby a user can load the latest version onto any PC (lin or win) and hit build/run with no issues.
Using QT 5.0.2
I have started to make two shadow configs, one for linux and one for windows (so the user will at least have to pick the right one of those I guess). I have two custom build steps (which are identical as the use the "cp" copy command which works in both lin and win). The main difference is the qmake call parameters. This stuff is all stored in the .pro.user file (there is also a .pro.user.xxxxxx file which appears to be more or less a copy of the .pro.user - perhaps a working copy).So, to keep both build I need to checkin my .pro.user file.... right?
Or is there now another way this is is done?Thanks!
-
No, you should never check in .pro.user* files. They are specific to one Qt Creator setup and can not be used with other Qt Creator instances.
I would recommend getting rid of the custom build steps by having the build system do the copying for you. Once you have done that the build becomes "qmake && make" and the default setup should be fine again on both linux and windows.
PS: The *.pro.user.xxxxxx file is there because you did copy a .user file to a different environment. Whenever creator sees a .user file that is not meant for its own environment it will copy it and append the start of the environment id found in the file to the new file name.
-
Hi Tobias, thanks for the reply :)
soo.... ok, I see what you are getting at. But I don't understand the part about letting the "build system" do the copying. I thought the custom steps is part of the build system :o
Also the default setup is not as I like it. I use it to put the output in a particular folder and I also redirect the console output to a log file (all done in the pro.user file).
It really seems to me that some of these settings are really useful as global project settings and not just single user/platform settings...
-
We try hard to make Creator play nice with command line tools. E.g. it should be easy to build your project without Creator. This makes it easier to integrate continuous integration systems and whatnot into your workflow: They just need a couple of commands to build your project (usually "qmake" followed by "make").
That is why we try to have the build system (be that qmake, auto-tools, cmake, qbs or whatever) do the heavy lifting! Those tools are made to build code and copy files around, etc. and do so in an intelligent way, too. So why duplicate that functionality in Creator again? It will only make it harder for people to build their stuff outside creator and is probably slower, too.
What I was suggesting is to add the "special code" you have into the .pro file itself. It can copy files, etc. for you, so why add custom build steps into creator to do that?
Redirecting output to a log file can obviously not be done with the build system as that happens after the build:) What is the use case for that? Creator can keep the application output logs around for you anyway...
-
Hi Tobias,
You are right, I had under-estimated the power of the .pro file itself, it can do a lot more then I realised :)
Using QMAKE_POST_LINK looks like you can do almost anything you want after the build is completed. I'll stick my example in here for peoples reference in case they end up going through the same search as me!:
@
Set the output paths
BUILD_DIR = ../_out
DESTDIR = $$BUILD_DIR
OBJECTS_DIR = $$BUILD_DIR
MOC_DIR = $$BUILD_DIR
RCC_DIR = $$BUILD_DIR
UI_DIR = $$BUILD_DIRPost build steps: copy xml config files from the project directory to the target location and also move the makefiles to keep
all of the output together.
QMAKE_POST_LINK += cp $$PRO_FILE_PWD/rpe.xml $$BUILD_DIR;
QMAKE_POST_LINK += cp $$PRO_FILE_PWD/rpeSim.xml $$BUILD_DIR;
QMAKE_POST_LINK += mv Makefile* $$BUILD_DIR;
QMAKE_POST_LINK += mv object_script* $$BUILD_DIR;Setup the compiler flags
QMAKE_CXXFLAGS += -Wall
#QMAKE_CXXFLAGS += -recursive
win* {
message (Building for windows target in $$BUILD_DIR)
QMAKE_CXXFLAGS += -std=gnu++11
}
linux* {
message (Building for linux target in $$BUILD_DIR)
#QMAKE_CXXFLAGS += -std=gnu++11
}
@Use case for redirecting my output is that I print useful messages to the screen via "stdout" so that while the program is running I can see what the current state is. I use "stderr" redirected to a file to send all my heavy-duty logging (message dumps, etc...)... So I simply add
@2> filename.log@To the run arguments, but ok, this is lazy, I could add a logging facility in my code :o
The last niggle I have is that by default when checkout a project from, say SVN, the default config is to use shadow build. This has a default folder, e.g.:
build-PROJNAME-Desktop_Qt_5_0_2_MinGW_32bit-Debug
Where is puts the make files. I have re-directed all the other files using things like:
@BUILD_DIR = ....@But there seems no way to specify where the make files go, and therefore to finally be rid of this folder. I manually move the make files to my final output directory with the QMAKE_POST_LINK. So in the end I am left with an empty folder. I was not able to use "rm" to delete it because it is "in use" at the time I need to do that.... so, I have a manual step to just turn off shadow builds if this extra folder annoys me that much (which it does not).
so it would be nice if there was a way to configure the shadow build (i.e. on/off)? -
Hey, I am using Qt 5.5.1. I want to configure shadow build (on/off) via the .pro itself since There is an overhead of clicking the shadow build checkbox. Please help me out if you have any solution for the same.
@Qt-Devils @Moderators @Qt-Champions-2014This is my .pro file:
OUT_PWD=$$PRO_FILE_PWD
PWD=$$PRO_FILE_PWD
INCLUDEPATH += $$PWD
DEPENDPATH += $$PWD
message($$OUT_PWD)
message($$PWD)
#QMAKE_MAKEFILE = /home/test/MST15_SSD_MSTK_SAS/Code/MSTK3.0_2015
#QMAKE_DISTCLEAN = /home/test/MST15_SSD_MSTK_SAS/Code//MSTK3.0_2015/
CLEAN_DEPS = $$PRO_FILE_PWD
message($$CLEAN_DEPS)BASEPATH = $$PRO_FILE_PWD
Makefile =$$PRO_FILE_PWD
message($$Makefile)
QMAKE_CLEAN = $$PWD
message($$QMAKE_CLEAN)CONFIG(debug, debug|release) {
BUILDDIR = $${BASEPATH}/debug
DLLDESTDIR = $${BASEPATH}/debug
DESTDIR = $${BASEPATH}/debugmessage($$DESTDIR_TARGET)
} else {
BUILDDIR = $${BASEPATH}/release
DESTDIR = $${BASEPATH}/release
}OBJECTS_DIR = $${BUILDDIR}
#PRECOMPILED_HEADER = $$PRO_FILE_PWD/debug
MOC_DIR = $${BUILDDIR}
RCC_DIR = $${BUILDDIR}
UI_DIR = $${BUILDDIR}
QMAKE_POST_LINK += cp $$PRO_FILE_PWD/rpe.xml $${BUILDDIR}
QMAKE_POST_LINK += cp $$PRO_FILE_PWD/rpeSim.xml $${BUILDDIR}
QMAKE_POST_LINK += mv Makefile* $${BUILDDIR}
QMAKE_POST_LINK += mv object_script* $${BUILDDIR}
QMAKE_CXXFLAGS += -Wallwin* {
message (Building for windows target in $BUILD_DIR)
QMAKE_CXXFLAGS += -std=gnu++11
}
linux* {
message (Building for linux target in $BUILD_DIR)
#QMAKE_CXXFLAGS += -std=gnu++11
}