[Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?

[Ed Sutton]

Hi André,

I apologize for my indents and reply formatting.  My Linux development VM host is running on OS X and I use Apple's Mail.  I prefer Thunderbird.  Unfortunately we have an Exchange mail server; Apple Mail works  with Exchange and Thunderbird not.  I will work on improving.

On May 12, 2010, at 11:37 AM, André Fillipe wrote:

While you ship a library, I'm shipping an application, which is more
self-contained, targeted at specific platforms and thus less prone to
the client environment.

Eventually I will need to do both ship a library and an application.  Probably as three rpm packages; myapi, myapi-devel, and myapiapplication.

So, instead of boring you with details of my
build process, I think you should take a look at one of the Qt
Solutions packages, QtSingleApplication, for example:

http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Utilities/qtsingleapplication/

The solutions are small add-ons that can be compiled as shared or
static libraries, they come with documentation, demos, etc. I feel
they are similar to what you are trying to achieve.

Extracted, then qmake'd the root *.pro, and make'd.  It all built and ran.  I knew how to load single instance of an app in Windows. Now with this Qt example I can do it on all the big OS's - cool.  I noticed all path assignments all use $$PWD instead of relative syntax.  Is there a reason I should not use relative paths such as "./lib" or "../docs" ?  I guess $$PWD is easier on the eyes than one '.' or two period '..' characters.

The passing of the XML file with a relative path is the only thing I
believe cannot be done, currently. Is this file expected to be in a
well-known location? It could then be searched for using
QDesktopServices.

I already had built-in supports for a default "configuration.xml" file name that it looks for in the working directory if none is specified on the command line.  For the demo application, I can just use this.  The KISS approach is better for a demo application anyway.

If it is bundled with the tarball and needs to be in the same folder
as the demo, you can create an extra target in the .pro file that
copies the XML file to the same location where the binary will be.
(More on this in the attached tarball.)

That's a nice solution.  Good idea.

We use rpath in our debug builds, only. If you install your release
libraries to the standard /usr/lib path, everything will work fine.
/usr/lib/<app> is normally used for modules and plugins specific to
the app itself. See this:

I like that idea; only use rpath for debug builds.

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

Thanks for the great file hierarchy reference.  I am currently working in the Red Hat Enterprise Linux 5.x world.  I just copied that  link to my Wiki.  :-)

I am packaging the dependent Qt shared libs along with mine under /usr/lib/myapi/.  I have read Qt docs on deployment.  I guess I was hoping to see a Qt run-time rpm package.  I guess my deployment concern is to avoid the Windows equivalent of "DLL hell" if we distribute multiple libs and apps that had been built and tested with different versions of Qt 4.x shared libs.  I am currently frozen on qt-sdk-linux-x86-opensource-2010.01.bin as I had an issue with a later version.

I did a simple test here, where I removed specific absolute paths from
the .pro.user file, moved the project dir around and opened it back in
Qt Creator. Everything worked fine, environment variables were
preserved. To keep it from being rewritten by Qt Creator, I simply
chmoded it to "a-w".

There might be a problem with the Qt configuration to use (the one you
set up in Tools > Options > Qt). I didn't have the time to test if it
breaks the build in a host with a different configuration.

All is good on this end including Tools > Options > Qt.  I extracted, built lib, built app, and ran from Qt Creator and received message that was in the text file.  I was not aware of *.pri files - thanks!  That's a nice way to clean-up the *.pro file.  I can see that technique being especially handy for supporting multiple target OSs.


See my note regarding rpath and /user/lib above. Remember to add a
VERSION configuration to your .pro file and update it when you release
new versions of you library.

Oops, that's was a key detail I was missing.  I was wondering how to set the lib version.  Very important tip.  Thanks you very much!

I am using a major.minor.svnRevision version format.  The major and minor numbers are human settable, the svnRevision increments with every commit.  I have a script that builds a non-version controlled version-svn.h.  I suppose I can modify to build a non-version controlled version-svn.pri file and include this in the *.pro file.

Are there guidelines for the shared lib version numbers? Is this okay?

VERSION  = 1.2.393

I am curious if you are using Ant or any other build or continuous integration tool?


See the tarball that I'm attaching. It is a small project consisting
of a library and an app. You should be able to untar, compile and run
it without any modifications (as long as the library is compiled first
- you can automate that with a SUBDIRS target with CONFIG += ordered).

I should do that too - have a *.pro file in my project root that uses SUBDIRS to build the lib, demo, and app projects.


The app depends on the library and reads information from the command
line, the environment and a text file. The app project ships with the
.pro.user file, but the absolute paths were removed. It could easily
be modified to compile against an installed version of the library
instead of the one inside the tarball, if required.

I also didn't have enough time to document the .pro and .pri files, so
if something is not clear, please ask.

Works great.

One question though, what is this section for in the test app?

# Extra compilers ----------------------------------------------------------------------------------
copy_cfg.name = "Copy Configuration"
copy_cfg.input = CONFIG_FILES
copy_cfg.output = ${QMAKE_FILE_BASE}${QMAKE_FILE_EXT}
copy_cfg.commands = $${QMAKE_COPY} \
    ${QMAKE_FILE_NAME} \
    ${QMAKE_FILE_OUT}
copy_cfg.CONFIG = no_link \
    target_predeps
QMAKE_EXTRA_COMPILERS += copy_cfg
CONFIG_FILES += $$PWD/message.txt

I hope I was able to help you with this.

I'll say. You have helped a lot! Thank your for your time and patience.

-Ed