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

[André Fillipe]

On Tue, May 11, 2010 at 7:54 PM, Ed Sutton <ESutton at fescorp.com> wrote:
>
> Having spent a lot of time on making a (mostly)
> automated-checkout-build-and-package process, I would be interested
> in hearing an overview of your build process.  I think I will grep
> some of the Qt .pro files myself to see what new tricks I may learn.

Hi again, Ed! Sorry for the delay.

I see that your issue is not really related to the build process, but
actually with running the demo binary.

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


> I probably just need to rethink things.  My goals are to be able to:
>
>  1.  Checkout a Qt project from Subversion ( or extract a tarball )
>  2.  Open Qt project file in Qt Creator
>  3.  Build
>  4.  Run execuable from Qt Creator
>  5.  or Start debugger from Qt Creator and debug step into the demo
>      source code
>
> I think it is mainly the running/debugging from Qt Creator that seems
> hard to accomplish without the "*.pro.user" files or requiring the user
> to setup an environment.


As I said, your build procedure seems quite standard. You can do
pretty much everything without too much qmake black magic.


> To run the demo executable, I have to set environment variables, tell
> it where to located the dynamic myapi libraries, and pass it an xml
> configuration file as a command line argument.


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.

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


> I can use rpath to tell it where to look for the libs (run-time search
> paths in general have been a learning curve under Linux as there seems
> to be about 4 ways to do it).


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:

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


> I am not sure about how to set an environment variable without the
> *.pro.user file.  The command line argument is solvable as long as I
> put the xml file it the same folder as the demo executable.


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.


>  *   I am building two rpm pacxkages from a single build.spec file;
>      myapi and myapi-devel.
>  *   The build.spec gets all source from Subversion, calls the build
>      scripts(qmake *.pro -r -spec linux-g++, make), and makes the two
>      rpms from the build output..
>  *   myapi rpm installs shared libraries to /usr/lib/myapi/


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.


>  *   myapi-devel installs the myapi header files to /usr/include/
>      myapi/,  Doxygen HTML documentation for the API, and a source code
>      example tarball containing a Qt project GUI project demonstrating
>      how to use the API
>
> I am hoping to reduce tech support calls.  I want the customer to be
> able to use Qt Creator and not have to mess about with any environment
> variables or settings.  Using Qt Creator I want him to be able to open
> the project, compile, run, and debug.  Just get him started quickly and
> easily with no setup configuration hassles.


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

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.


> After making a couple attempts at using Eclipse C++ (with Qt
> integration), I keep coming back to Qt Creator.  I agree I have seen
> nothing better for a C++ Linux IDE and for my development I intend to
> stick with it.  And if I can get a few new customers hooked I am happy
> to spread the word. :-)


I hope I was able to help you with this.


Cheers.

-- 
André Fillipe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build-test.tar.gz
Type: application/x-gzip
Size: 3318 bytes
Desc: not available
Url : http://lists.qt-project.org/pipermail/qt-creator-old/attachments/20100512/76d3665f/attachment.gz