On Tue, May 11, 2010 at 7:54 PM, Ed Sutton <[email protected]> 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
build-test.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Qt-creator mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-creator
