Crossplatform .pro.user project file
-
I have a few projects for which I share the project folders between my host OS (Linux) and a few windows VMs (different versions of windows, 32/64 -bit, different configurations, etc).
So there are different Qt Creator instances using the exact same folder.
I would like the different instances of Qt Creator to keep their own .pro.user file. It used to work this way, maybe for years, but now it doesn't. Can Qt Creator still do this?I've read other posts on this subject, yes, I use a VCS. But that doesn't help me here.
If I'm going to add a new feature to my project I don't want to develop in my host environment, commit changes, go to each VM, check-out, etc.
I want to write the code once, then go to each other environment, build, test, done.
Then, once I'm happy with everything, I'll commit once from my host environment.
Since each different environment uses the same shared folder, I can accomplish this without copying files around or doing commit/checkout for each environment - save for the .pro.user issue.I don't want to have to copy stuff to each VM to run and test...that is insanity.
I don't want different .pro files for each environment...that defeats some of the "write-once, build everywhere" capabilities.This same setup worked fine for quite some time, years maybe. I think it stopped working when I installed Qt Creator 2.7 everywhere. I think it worked previously because the .pro.user files were named differently: for example I have a project folder with a .pro.user.2.5pre1 that has settings for one of the windows VMs, and also a .pro.user.2.6pre1 file that has settings for the host (linux) environment.
How can I get Qt Creator back to this mode of operation?
Thanks... -
Hi,
I don't know how to make it work like your old system. But I do know that if Qt Creator finds an incompatible .pro.user file, it will prompt you to reconfigure your project (which should take only 2 clicks if you only have one version of Qt on your machine). Is that an acceptable compromise?
.pro.user files are machine-specific and can't be made cross-platform, unfortunately. They don't even work on different machines of the same platform.
-
well, I setup shadow build (I think is what it's called), so it's a few more clicks...and it is required each time a different environment opens the project (not just once per environment, per project). It's like if I open the project in environment B, it blows away the setttings for envirnoment A...so when I return to evn. A, I have to jump through all the hoops again...and then again when I go back to env. B.
A nice feature would be to allow Qt Creator to create .pro.user file names that are unique to the Qt Creator instance, so that each instance uses it's own file and isn't bothered by other instances' files.
I'm not sure exactly how feasible that is at present, but it seems it used to work that way just fine.
-
Another option is develop in one platform (using QtCreator), and call qmake + make (shell) on the others (like buildserver's do)
-
In qmake help, look for CONFIG variable and how one you use it.
You can identify possible set of values CONFIG can take and then have conditional enabling in your .pro file based on the platform under consideration. -
Here we used some "variables":http://qt-project.org/doc/qt-4.8/qmake-variable-reference.html to define different setting depending on compiler / arch.
Here an example we used to define different libs depending on architecture (x86 or x64) - Windows, compiled with msvc.
@
QT += core guigreaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = FixPerformanceTester
TEMPLATE = appwin32-msvc*: {
INCLUDEPATH += ..\..\legado\libraries\vc100\include
LIBS += Ws2_32.libcontains(QMAKE_HOST.arch, x86_64): { CONFIG(debug, debug|release): { LIBS += ..\\..\\legado\\libraries\\vc100\\lib\\x64\\debug\\quickfix.lib } else { LIBS += ..\\..\\legado\\libraries\\vc100\\lib\\x64\\release\\quickfix.lib } } else { CONFIG(debug, debug|release): { LIBS += ..\\..\\legado\\libraries\\vc100\\lib\\win32\\debug\\quickfix.lib } else { LIBS += ..\\..\\legado\\libraries\\vc100\\lib\\win32\\release\\quickfix.lib } }
}
SOURCES += main.cpp
mainwindow.cpp
quickfixapplication.cpp
engine.cppHEADERS += mainwindow.h
quickfixapplication.h
engine.hFORMS += mainwindow.ui
OTHER_FILES +=
teste.cfg
FIX42.xml
@ -
[quote author="username31480" date="1377807281"]well, I setup shadow build (I think is what it's called), so it's a few more clicks...[/quote]What do you mean? Shadow builds are enabled by default. Just click "Configure Project" when the screen appears to accept it.
You can set the default build directory for each VM at Tools -> Options -> Build & Run -> General
You can also request the feature at https://bugreports.qt-project.org/
-
What surprises me is that you claim this used to work!
So where do all the different extensions from the .user file come from? Basically there are two kinds:
First is .user.SomeVersionNumber (like .user.2.6pre1). These are created as part of the update process: When installing a new version of QtC it may require a different format for the .user files. To do so we have a upgrade machanism in place which does a copy of the old version and then updates it to the new syntax and then saves the new version in the .user file. So when upgrading QtC you will most likely see those appear. They can be safely removed once you made sure that the update went smoothly and you are sure that you will not end up loading the project into an older version of QtC again. Old versions will try to load older versioned .user files if the .user file is too new.
Secondly we now have .user files with a 6 digit hex number appended. Those appear when one Creator runs into .user files that were made by other installations ot Creator. You should be getting those. When Creator finds a .user file that it did not write itself, then it will copy it to .user.6digits and then proceed to load it (throwing away settings it does not know) and will then write its own .user file. Starting with QtC 3.0 (maybe that is already in 2.8, not 100% sure though), creator will load its own .user.6digits file if the .user file does not match up, so your use case should work a bit better with those versions (which is why I am a bit surprised that you claim this worked before;-).
Hope this helps to understand what is going on...
For your use case I would recommend setting the "QTC_EXTENSION" environment variable to be unique for each of your installations. This variable can be used to override the default .user extension. That way all your environments will write into their own file and you won't see any mix-ups.