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

[André Fillipe]

On Wed, May 12, 2010 at 7:02 PM, Ed Sutton <ESutton at fescorp.com> wrote:
>
> I apologize for my indents and reply formatting.


At least to me, no need to. Gmail color-coded the thread and I could
read it just fine.


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


The trick with including .pri files instead of setting the -I, -L, -l
and -rpath switches in every app project that consumes a library is a
great time saver.


> 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.


If a file contains $$PWD, $$PWD will always mean "that file's
directory". The meaning of '.' and '..' changes on context. That's an
important difference when you start including .pri files from other
projects.


> 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.


Another trick we use a lot here is bundling such necessary immutable
files inside the application binary using the Qt Resource system.


> 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.


In theory, you don't have to worry if the host version of Qt is newer
than the one your code was built against. I've seen things break,
however. It is indeed better to avoid the chaos. Rpath in the release
version saves you headaches in this case.


> Are there guidelines for the shared lib version numbers? Is this okay?
>
> VERSION  = 1.2.393


I don't really know. The numbering is somehow tied to the library
binary interface. That is something I still have to learn. Someone
here referred me to this paper by a Sun engineer (that I haven't read
yet):

http://www.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/

Defining the binary interface of a C++ library and pinpointing changes
that break it is not so trivial. Nokia's Thiago Macieira has written
extensively about it:

- http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
- http://labs.trolltech.com/blogs/2009/08/12/some-thoughts-on-binary-compatibility/


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


Not yet. Our codebase just became "easy to build" this week :) We are
also waiting for Nokia's position regarding the improved build system
mentioned in the Qt Roadmap. We'll do cron-based nightlies while we
wait...


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


That is the extra build step I mentioned. It copies the message.txt
file alongside the app binary. If you didn't see it in action maybe
it's because you ran qmake inside the project directory - there's no
need to copy the file it in this case. If you set up a shadow build in
Qt Creator it will certainly run.

Creating new build steps is explained here:

- http://doc.qt.nokia.com/4.6/qmake-environment-reference.html#customizing-makefile-output
- http://www.qtcentre.org/wiki/index.php?title=Undocumented_qmake#Custom_tools


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


You are welcome. I'm very glad I could help!

-- 
André Fillipe