Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
Hi André,
On May 12, 2010, at 6:13 PM, André Fillipe wrote:
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/
Thanks for the article. Using the Subversion revision number as the micro
should fit fine in the major.minor.micro pattern.
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 agree it requires careful thought. After reading, I added the links you sent
to our wiki.
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.
I see running make copies message.txt to message in the Test folder. I am
still trying to correlate that copy action to the syntax I see in Test.pro
pasted below:
# 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
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
There is a lot in these articles I was not aware of. How to apply this is
still not clear to me. For each Qt project I have an associated build script.
Perhaps with enough qmake study I can move it all into qmake. My scripts do
the following:
qmake *.pro -r -spec linux-g++
make clean
make
# copy dependent libraries to build output directory
doxygen Doxyfile
Anyway, I will keep reading about qmake using the links you sent and it should
make since eventually. I did a Google code search of *.pro files to find more
examples
http://www.google.com/codesearch?as_q=QMAKE_COPYbtnG=Search+Codehl=enas_lang=as_license_restrict=ias_license=as_package=as_filename=proas_case=
Thank you again for your time and for the valuable reference links.
-Ed
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
On Tue, May 11, 2010 at 7:54 PM, Ed Sutton esut...@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
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
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
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
Hi André, Sorry, I saw that my vertical reply-indent bars disappeared in the post. Here's another with '' inserted. 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 implemented support 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
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
On Wed, May 12, 2010 at 7:02 PM, Ed Sutton esut...@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 ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
My goal is to make a Qt project runnable from any user's Linux home directory (no hard coded paths). I tried setting the working directory setting found under Project-Run Settings-Running Executable-Working Directory? That your app depends on the working directory is the problem. Depending on how (and on which OS) your app is started, the working directory will contain all kind of interesting values. You should try to locate your data relative to e.g. QApplication::applicationDirPath(), or QDesktopServices::storageLocation(). I am not sure I understand. I am trying to make the Qt Creator project run settings paths relative (no hard-coded absolute paths ). I want any Red Hat Enterprise Linux developer to be able to extract a project tarball to his home directory, open the Qt project file and be able to build, run, and debug from within Qt Creator without having to modify any Qt Creator project setings. The problem is the Qt project Working Directory Run Setting seems to only accept hard-coded absolute paths. You mean I can access Qt class static methods in the *Qt Creator* project run settings? Or are you saying it cannot be done and the best I can do is to use these static methods at run-time? Thank you for your help, -Ed ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
On Tue, May 11, 2010 at 1:45 PM, Ed Sutton esut...@fescorp.com wrote: I am not sure I understand. I am trying to make the Qt Creator project run settings paths relative (no hard-coded absolute paths ). I want any Red Hat Enterprise Linux developer to be able to extract a project tarball to his home directory, open the Qt project file and be able to build, run, and debug from within Qt Creator without having to modify any Qt Creator project setings. The problem is the Qt project Working Directory Run Setting seems to only accept hard-coded absolute paths. Are you including the .pro.user files in the tarball? If you are, you shouldn't. -- André Fillipe ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
Or are you saying it cannot be done and the best I can do is to use these static methods at run-time? We're saying that the run-time solution is superior in general. Working directory is a notoriously fickle beast and it can change just depending on how you happen to invoke the program. The static methods, however, will always return a consistent path no matter how you invoke the application. /s/ Adam ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
On May 11, 2010, at 12:38 PM, André Fillipe wrote: On Tue, May 11, 2010 at 1:45 PM, Ed Sutton esut...@fescorp.commailto:esut...@fescorp.com wrote: I am not sure I understand. I am trying to make the Qt Creator project run settings paths relative (no hard-coded absolute paths ). I want any Red Hat Enterprise Linux developer to be able to extract a project tarball to his home directory, open the Qt project file and be able to build, run, and debug from within Qt Creator without having to modify any Qt Creator project setings. The problem is the Qt project Working Directory Run Setting seems to only accept hard-coded absolute paths. Are you including the .pro.user files in the tarball? If you are, you shouldn't. Yes, I am. I have also included the .pro.user files in version control. Is the preferred alternative to not rely on Qt Creator project settings at all? Basically everything should be persisted in the *.pro file? Obviously if I delete the .pro.user file I lose all Qt Project settings; custom build steps, build environment, run settings, and run environment settings. I had added an environment variable required by a 3rd-party library to the run settings environment. The pro.user persisted this and without this file a user cannot simply extract, open a project in Qt Creator, build, and run. I will need to think about alternatives. Coming from Windows Visual Studio 2008 I saw Qt Creator as a viable replacement tool (or maybe a crutch) in my new Linux world. I viewed the Qt *.pro files as the equivalent to Visual Studio's project *.sln solution file and *.csproj project file which I typically versioned control as well. Thank you both for sharing your experience and time. -Ed ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
On 05/11/2010 10:39 PM, Ed Sutton wrote: Obviously if I delete the .pro.user file I lose all Qt Project settings; custom build steps, build environment, run settings, and run environment settings. I had added an environment variable required by a 3rd-party library to the run settings environment. The pro.user persisted this and without this file a user cannot simply extract, open a project in Qt Creator, build, and run. I will need to think about alternatives. Users shouldn't even need to use Qt Creator. All they need is: qmake myproject.pro make Any tweaks you need should be coded inside the *.pro file. The qmake reference docs contain everything you need. ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
Any tweaks you need should be coded inside the *.pro file.
True.
The qmake reference docs contain everything you need.
Quite the opposite: qmake is probably the worst documented part of Qt.
Try and search for any info on $$qtLibraryTarget, the fakelib
template, $$files and the such. I spent this weekend rewriting my
team's convoluted build process and my best source of reference were
Qt Solutions .pro files. And lots of trial and error. We now build and
package straight from checkout, but it was a chore.
The improved build system in the Qt Roadmap is the feature I am most
anxious about. Qmake is showing its age and none of the replacements
are good enough.
Coming from Windows Visual Studio 2008 I saw Qt Creator as
a viable replacement tool (or maybe a crutch) in my new
Linux world. I viewed the Qt *.pro files as the equivalent
to Visual Studio's project *.sln solution file and *.csproj
project file which I typically versioned control as well.
They are. The *.pro.user files, however, are like the
*.vcproj.{machine}.{username}.user files which you usually shouldn't
version.
If you clarify what you are trying to accomplish (no need to go into
NDA-breaching specifics), maybe I can assist you. I think Qt Creator
is currently the best C++ IDE available for Linux and it would be a
shame not to use it.
--
André Fillipe
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
On May 11, 2010, at 4:08 PM, André Fillipe wrote:
Any tweaks you need should be coded inside the *.pro file.
True.
The qmake reference docs contain everything you need.
Quite the opposite: qmake is probably the worst documented part of Qt.
Try and search for any info on $$qtLibraryTarget, the fakelib
template, $$files and the such. I spent this weekend rewriting my
team's convoluted build process and my best source of reference were
Qt Solutions .pro files. And lots of trial and error. We now build and
package straight from checkout, but it was a chore.
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.
The improved build system in the Qt Roadmap is the feature I am most
anxious about. Qmake is showing its age and none of the replacements
are good enough.
Coming from Windows Visual Studio 2008 I saw Qt Creator as
a viable replacement tool (or maybe a crutch) in my new
Linux world. I viewed the Qt *.pro files as the equivalent
to Visual Studio's project *.sln solution file and *.csproj
project file which I typically versioned control as well.
They are. The *.pro.user files, however, are like the
*.vcproj.{machine}.{username}.user files which you usually shouldn't
version.
If you clarify what you are trying to accomplish (no need to go into
NDA-breaching specifics), maybe I can assist you.
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.
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.
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). 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 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/
* 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.
I think Qt Creator
is currently the best C++ IDE available for Linux and it would be a
shame not to use it.
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. :-)
Thank you very much for your assistance,
-Ed
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
I am totally unable to tell which part of your text is a quote and which
is something you wrote as a reply :-/
On 05/12/2010 01:54 AM, Ed Sutton wrote:
On May 11, 2010, at 4:08 PM, André Fillipe wrote:
Any tweaks you need should be coded inside the *.pro file.
True.
The qmake reference docs contain everything you need.
Quite the opposite: qmake is probably the worst documented part of Qt.
Try and search for any info on $$qtLibraryTarget, the fakelib
template, $$files and the such. I spent this weekend rewriting my
team's convoluted build process and my best source of reference were
Qt Solutions .pro files. And lots of trial and error. We now build and
package straight from checkout, but it was a chore.
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.
The improved build system in the Qt Roadmap is the feature I am most
anxious about. Qmake is showing its age and none of the replacements
are good enough.
Coming from Windows Visual Studio 2008 I saw Qt Creator as
a viable replacement tool (or maybe a crutch) in my new
Linux world. I viewed the Qt *.pro files as the equivalent
to Visual Studio's project *.sln solution file and *.csproj
project file which I typically versioned control as well.
They are. The *.pro.user files, however, are like the
*.vcproj.{machine}.{username}.user files which you usually shouldn't
version.
If you clarify what you are trying to accomplish (no need to go into
NDA-breaching specifics), maybe I can assist you.
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.
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.
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). 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 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/
* 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.
I think Qt Creator
is currently the best C++ IDE available for Linux and it would be a
shame not to use it.
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. :-)
Thank you very much for your assistance,
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
[Qt-creator] Qt Build Settings can use $BUILDIR. Why not Project Run Settings?
My goal is to make a Qt project runnable from any user's Linux home directory
(no hard coded paths). Are Qt variables not accessible in the Project Run
Settings?
In my Qt project file I set:
TARGET = democlient
DESTDIR = ../bin
I tried setting the working directory setting found under Project-Run
Settings-Running Executable-Working Directory?
DESTDIR
$DESTDIR
$$DESTDIR
$${DESTDIR}
The compile output says:
Starting
/home/esutton/rpm/BUILD/libfesvideo-1.2.309/example-democlient/bin/democlient...
Cannot change to working directory '$DESTDIR': No such file or directory
Thanks in advance for any tips or direction ( I am still learning Linux and Qt
).
-Ed
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
