.qmake.cache is good, except QtCreator doesn't read it?
-
I was reading this post "http://qt-project.org/wiki/QMake-top-level-srcdir-and-builddir":http://qt-project.org/wiki/QMake-top-level-srcdir-and-builddir (unfortunately no comments on page are allowed) I am very interested in .cmake.cache to set global variables, but it does not seem to work with QtCreator (and likely with other build systems).
I created a dummy project ("here":http://cl.ly/0O452h1y301E) where the content of the cache file is simply "error(READ CACHE FILE)". When I run qmake from the command line it seems to work:
@
ata2 % lira ~/Developer/qmakecache: qmake qmakecache.pro
Project ERROR: READ CACHE FILE
@But when I try to do the same from qtcreator:
@
14:25:05: Running steps for project qmakecache...
14:25:05: Starting: "/Users/ata2/Developer/QtSDK/Desktop/Qt/4.8.1/gcc/bin/qmake" /Users/ata2/Developer/qmakecache/qmakecache.pro -r -spec macx-g++ CONFIG+=x86_64 CONFIG+=declarative_debug
14:25:05: The process "/Users/ata2/Developer/QtSDK/Desktop/Qt/4.8.1/gcc/bin/qmake" exited normally.
@ -
Make sure you've manually deleted the resulting .qmake.cache file. qmake obviously doesn't re-create .qmake.cache if the file already exists.
Interestingly enough $$PWD did not work for me in the qmake.cache.in (was empty), but $$PRO_FILE_PWD did.
-
I understood the problem. It had to do with shadow-builds, not qtcreator. The file is looked for in the shadow build directory. This was not well specified in the qmake documentation (as I very often find).
Let me add, this makes .qmake.cache files useless for this purpose (excerpt from page linked above):
@
The first feature is the .qmake.cache file, which is technically a .pri file that gets automatically included in every .pro file your project contains, including those in subdirectories. It’s the perfect place to define variables and settings that apply to all your .pro files, such as (you guessed it) top_srcdir and top_builddir.
@... sadly
... very sadly -
It works quite well for me even with shadow-builds.
@
src/.qmake.cache.in:
BUILD_DIRECTORY=$${OUT_PWD}
SOURCE_DIRECTORY=$${PRO_FILE_PWD}src/.qmake.cache.pro:
TEMPLATE = subdirs
SUBDIRS =
QMAKE_SUBSTITUTES += .qmake.cache.insrc/project.pro:
TEMPLATE = subdirs
SUBDIRS += .qmake.cache.pro src
@
Which results in a <code>.qmake.cache</code> file placed in the shadow build directory, containing the BUILD_DIRECTORY and SOURCE_DIRECTORY variables set with apropriate values.Is this what you are looking for, or are you trying to achieve something different?
-
I am trying to achieve something very similar, but I strongly disagree this is an elegant solution.
It is utterly counter-intuitive!! The only reason for which your .qmake.cache file is created is because the QMAKE_SUBSTITUTE is shadow-build-aware.Still, this is a HUGE price to pay for something as simple as global variables.
This is much cleaner and intuitive:
@
src/project.pro:
system(qmake -set GLOBALS src/globals.prf)
...src/subproject.pro
load($$[GLOBALS])
...
@ -
because include files need relative paths, so you quickly end up with code that looks like:
@
src/subproject.pro
include(../../../../../../project.pri)
@That's why I was really looking forward to the .cmake.cache, because it's looked
for recursively up the code tree, without me having to specify any relative paths. -
Alright, I think I misunderstood your inital reply.
The most obvious solution is qmake taking .qmake.cache from source directories as well, with precedence to the build directory if both are present to maintain compatibility.
"Patches are welcome.":https://codereview.qt-project.org
Until then the provided .qmake.cache.in workaround is (imho quite a viable) solution and it should be officially documented somewhere; at least it is better than the relative path hell, which I have gone through as well ;-)
-
Lukas, yes, now you exactly understand what I intended. I am just very against sticking some configuration stuff inside a hidden file... It will drive some people crazy!!!
The people working on QMake really need to do something to provide people the tools to maintain a large application. What they offer now only works for small scale stuff.
p.s.
By the way, did you ever wonder why the .pro.user is created INSIDE the source folder? This is VERY bad when I want to compile the project simultaneously on different OSs (I share the source folder across multiple virtual machines). -
<code>.qmake.cache</code> might be a unfortunate choice as it leads to an hidden file on Unixoid systems, although it follows the schema for local configuration files (like <code>.gitignore</code>).
But I don't think this disqualifies qmake for large scale projects. Qt itself uses qmake and we use it for large scale projects as well.
The .pro.user is created by Qt Creator to store project-specific stuff. It isn't related to Qt or qmake. As far as I know the Qt Creator team itself isn't quite happy on its own with the current solution, so expect improvments in the future.
But the advice stays the same. Either spend your time to fix it on your own and preferably contribute the changes or file a bug report and see if others find your problem important enough to spend their time.
As a last resort Qt works quite well with other build systems as well, like cmake.
-
I am really looking forward to the improvements to the "*.pro.user"
I also wish there was a better way of decomposing a large project in libraries.
qmake does not go all the way in achieving this... It'd be awesome if Qt had
its own version of "Frameworks" (like Apple's) as a build template. -
Remove .qmake.stash and .qmake.super files in Users/your_username.