Re: [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  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?

[Ed Sutton]

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/ 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 sh

Re: [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/ 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.

Re: [Qt-creator] Significant slow down with the 2.0 beta on mac

[alan.westbrook]

Ok, good news.

It turns out that I had a few instances of Creator spewed about, one in 
/Developer/Applications/Qt/ for some reason, it was old, and one in my sources 
dir that I must have grabbed a while ago and built before the beta came out.

Deleting all the old versions made things MUCH better (and improved font 
rendering in the editor somehow).

So let this be a lesson! Clean out your old software! =)

Alan

On May 12, 2010, at 1:41 PM, ext 
alan.westbr...@nokia.com wrote:

I did notice 741 console error messages originating from Creator that took 
place in the space of about 6 seconds from earlier today if anyone from the 
Creator team is interested.

Alan

On May 12, 2010, at 1:34 PM, ext 
alan.westbr...@nokia.com wrote:

Hello,

I am using the Creator 2.0 beta

"Qt Creator 1.3.82
Based on Qt 4.7.0 (64 bit)

Built on Mar 19 2010 at 11:56:02"

On the mac, and with this version, there are now a lot of UI freezes with 
spinning wait cursor showing up when just using it normally (typing, scrolling, 
opening menus ...).

Any ideas what might be causing this behavior?

Thanks!
Alan





___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] Significant slow down with the 2.0 beta on mac

[alan.westbrook]

I did notice 741 console error messages originating from Creator that took 
place in the space of about 6 seconds from earlier today if anyone from the 
Creator team is interested.

Alan

On May 12, 2010, at 1:34 PM, ext 
alan.westbr...@nokia.com wrote:

Hello,

I am using the Creator 2.0 beta

"Qt Creator 1.3.82
Based on Qt 4.7.0 (64 bit)

Built on Mar 19 2010 at 11:56:02"

On the mac, and with this version, there are now a lot of UI freezes with 
spinning wait cursor showing up when just using it normally (typing, scrolling, 
opening menus ...).

Any ideas what might be causing this behavior?

Thanks!
Alan



___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

[Qt-creator] Significant slow down with the 2.0 beta on mac

[alan.westbrook]

Hello,

I am using the Creator 2.0 beta

"Qt Creator 1.3.82
Based on Qt 4.7.0 (64 bit)

Built on Mar 19 2010 at 11:56:02"

On the mac, and with this version, there are now a lot of UI freezes with 
spinning wait cursor showing up when just using it normally (typing, scrolling, 
opening menus ...).

Any ideas what might be causing this behavior?

Thanks!
Alan

___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] Small (but great) mouse button feature request

[Oswald Buddenhagen]

On Wed, May 12, 2010 at 06:11:38PM +0200, ext bd.a...@free.fr wrote:
> Browsers allow to move back to the previous (next) page using the 4th
> (5th) button on 5 button mouse.
> 
alt-left (-right)?

___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] Small (but great) mouse button feature request

[bd . anon]

Le Wed, 12 May 2010 18:26:02 +0200, Robert Hairgrove
  écrivait:

>If I am typing at the keyboard, F2 is ALWAYS easier to use than looking 
>for the mouse.

True in general, but not in this specific use case : When you want to
look up a symbol, you frequently use the mouse to point to the symbol,
and then your hand has to abandon the mouse, usually to the right of
the keyboard, to move all the way to the F2 key, which happen to be on
the upper left part of the keyboard.

Would be much faster to use the currently unused 4th button, and the
5th to go back to the original place.

In any case, I certainly do not suggest this as a replacement for the
F2 key, but as an additional convenience to achieve the same effect,
for those who do use the mouse.

___
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?

[André Fillipe]

On Tue, May 11, 2010 at 7:54 PM, Ed Sutton  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/ 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

Re: [Qt-creator] Small (but great) mouse button feature request

[Robert Hairgrove]

bd.a...@free.fr wrote:
> Browsers allow to move back to the previous (next) page using the 4th
> (5th) button on 5 button mouse.
> 
> I would love to see Creator implement the same type of action with the
> 5th button when, having used the F2 key to go to a definition, it is
> time to go back to the original source code.
> 
> Would be even greater if the 4th button had the same effect as the F2
> key.
> 
> It's a small feature, but it would save lot's of time, and perhaps
> more importantly, would allow the hand to automatically check
> definition and go back to source code nearly unconsciously, without
> disrupting the chain of thoughts...
> 
> Should be simple to implement, as the code to navigate the code is
> already build within Creator.

If I am typing at the keyboard, F2 is ALWAYS easier to use than looking 
for the mouse. But everyone has their own habits... (I really HATE using 
the mouse if I don't absolutely have to do it, especially since I code a 
lot on a laptop, in the train, etc.)
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

[Qt-creator] Small (but great) mouse button feature request

[bd . anon]

Browsers allow to move back to the previous (next) page using the 4th
(5th) button on 5 button mouse.

I would love to see Creator implement the same type of action with the
5th button when, having used the F2 key to go to a definition, it is
time to go back to the original source code.

Would be even greater if the 4th button had the same effect as the F2
key.

It's a small feature, but it would save lot's of time, and perhaps
more importantly, would allow the hand to automatically check
definition and go back to source code nearly unconsciously, without
disrupting the chain of thoughts...

Should be simple to implement, as the code to navigate the code is
already build within Creator.

___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] Compilation issues while building webkit on QTCreator

[Eike Ziller]

Hej,

On May 12, 2010, at 2:32 PM, ext Rajasekhar M wrote:

> Hi,
>To run through the webkit source code using simulator, i was trying to 
> build it over QT-Creator, I followed the following steps.
> 
> 1. Installed Nokia QT SDK linux flavour.
> 2. Opened the project 
> "NokiaQtSDK/QtSources/4.7.0/src/3rdparty/webkit/webkit.pro"
> 3. Build Settings :
>"qmake-qt4 Webkit.pro -r spec linux-g++ CONFIG+=debug"
> 
> it failed with the following errors. Any clue on how to resolve these ?

It might be that you miss the libx11-dev packages. You need to make sure you 
have installed a few development packages from your Linux distribution, see the 
Linux requirements here:

http://doc.qt.nokia.com/qtcreator-snapshot/creator-os-supported-platforms.html

Best regards,
Eike

-- 
Eike Ziller
Software Engineer
Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori




___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

[Qt-creator] Compilation issues while building webkit on QTCreator

[Rajasekhar M]

Hi,
   To run through the webkit source code using simulator, i was trying to
build it over QT-Creator, I followed the following steps.

*1. Installed Nokia QT SDK linux flavour.*
*2. Opened the project "NokiaQtSDK/QtSources/4.7.0/src/3rdparty/webkit/
webkit.pro"*
*3. Build Settings :*
*   "**qmake-qt4 Webkit.pro -r spec linux-g++ CONFIG+=debug"*

it failed with the following errors. Any clue on how to resolve these ?

---

In file included from
/home/test/NokiaQtSDK/Simulator/Qt/gcc/include/QtGui/QX11EmbedContainer:1,
from ../../webkit/WebCore/plugins/qt/PluginContainerQt.h:22,
from ../../webkit/WebCore/plugins/qt/PluginContainerQt.cpp:21:
/home/test/NokiaQtSDK/Simulator/Qt/gcc/include/QtGui/qx11embed_x11.h:77:
error: XEvent has not been declared
/home/test/NokiaQtSDK/Simulator/Qt/gcc/include/QtGui/qx11embed_x11.h:115:
error: XEvent has not been declared
In file included from
../../webkit/WebCore/plugins/qt/PluginContainerQt.cpp:21:
../../webkit/WebCore/plugins/qt/PluginContainerQt.h:38: error: XEvent has
not been declared
../../webkit/WebCore/plugins/qt/PluginContainerQt.h:56: error: XEvent has
not been declared
../../webkit/WebCore/plugins/qt/PluginContainerQt.cpp:56: error: prototype
for bool WebCore::PluginClientWrapper::x11Event(XEvent*) does not match any
in class WebCore::PluginClientWrapper
../../webkit/WebCore/plugins/qt/PluginContainerQt.h:56: error: candidate is:
bool WebCore::PluginClientWrapper::x11Event(int*)
../../webkit/WebCore/plugins/qt/PluginContainerQt.cpp: In member function
void WebCore::PluginContainerQt::redirectWheelEventsToParent(bool):
../../webkit/WebCore/plugins/qt/PluginContainerQt.cpp:110: error: x11Info
was not declared in this scope
../../webkit/WebCore/plugins/qt/PluginContainerQt.cpp:113: error: x11Info
was not declared in this scope
../../webkit/WebCore/plugins/qt/PluginContainerQt.cpp: At global scope:
../../webkit/WebCore/plugins/qt/PluginContainerQt.cpp:117: error: prototype
for bool WebCore::PluginContainerQt::x11Event(XEvent*) does not match any in
class WebCore::PluginContainerQt
../../webkit/WebCore/plugins/qt/PluginContainerQt.h:38: error: candidate is:
virtual bool WebCore::PluginContainerQt::x11Event(int*)
make[1]: Leaving directory
`/home/test/NokiaQtSDK/QtSources/4.7.0/src/3rdparty/WebKit-build/WebCore'
make[1]: *** [PluginContainerQt.o] Error 1
make: Leaving directory
`/home/test/NokiaQtSDK/QtSources/4.7.0/src/3rdparty/WebKit-build'
make: *** [sub-WebCore-make_default-ordered] Error 2
Exited with code 2.
Error while building project WebKit (target: Qt Simulator)
When executing build step 'Make'
--


Thanks
Raja
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] Unable to debug application on-device using Qt-Creator and MADDE (TP2)

[André Pönitz]

On Wednesday 12 May 2010 12:28:32 ext Rudenko Eugene wrote:
> Hello Andre.
> yes, you wright, there are no "-g" flag, but  AFAIK, if you add CONFIG+=debug 
> option to qmake, it included  "-g" flag.
> 
> Here is my default qmake options for Debug config.
> "qmake /Users/rule/development/MAEMO/maemo_test2/maemo_test2.pro -r -spec 
> linux-g++-gles2 CONFIG+=debug"
> 
> Although  I can add "QMAKE_CXX_DEBUG += -g" I believe that it should be made 
> by qmake.
> Maybe something wrong with qmake.conf in MADDE ?

Yes, looks indeed like a broken qmake.conf in your version of MADDE.

Andre'
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] Unable to debug application on-device using Qt-Creator and MADDE (TP2)

[Rudenko Eugene]

Hello Andre.
yes, you wright, there are no "-g" flag, but  AFAIK, if you add CONFIG+=debug 
option to qmake, it included  "-g" flag.

Here is my default qmake options for Debug config.
"qmake /Users/rule/development/MAEMO/maemo_test2/maemo_test2.pro -r -spec 
linux-g++-gles2 CONFIG+=debug"

Although  I can add "QMAKE_CXX_DEBUG += -g" I believe that it should be made by 
qmake.
Maybe something wrong with qmake.conf in MADDE ?





> On Wednesday 12 May 2010 11:30:36 ext Rudenko Eugene wrote:
>> Hello, I'm trying to debug on device.
>> I configured all and application compiled and run on device well, but it not 
>> stopped on any breakpoints.
>> Qt-creator - 1.3.82 From revision 017ea83680
>> MADDE  - TP2 0.6.14
>> 
>> I attached debugger output.
> 
> [Full output usually helps best]
> 
>> I found a couple of strange messages in it:
>> 
>> =
>> dATTEMPT BREAKPOINT SYNC
>> <257-break-insert "\"mainwindow.cpp\":33"
>> <258-break-insert "\"main.cpp\":7"
>>> &"No source file named mainwindow.cpp.\n"
> 
> This looks like you are trying to debug a binary that was not compiled
> with -g.
> 
> Please check the "Compile Output" pane and verify it mentions -g on
> the g++ command lines.
> 
> Andre'
> ___
> Qt-creator mailing list
> Qt-creator@trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator

___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] Unable to debug application on-device using Qt-Creator and MADDE (TP2)

[André Pönitz]

On Wednesday 12 May 2010 11:30:36 ext Rudenko Eugene wrote:
> Hello, I'm trying to debug on device.
> I configured all and application compiled and run on device well, but it not 
> stopped on any breakpoints.
> Qt-creator - 1.3.82 From revision 017ea83680
> MADDE  - TP2 0.6.14
> 
> I attached debugger output.

[Full output usually helps best]

> I found a couple of strange messages in it:
> 
>  =
> dATTEMPT BREAKPOINT SYNC
> <257-break-insert "\"mainwindow.cpp\":33"
> <258-break-insert "\"main.cpp\":7"
> >&"No source file named mainwindow.cpp.\n"

This looks like you are trying to debug a binary that was not compiled
with -g.

Please check the "Compile Output" pane and verify it mentions -g on
the g++ command lines.

Andre'
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

[Qt-creator] Unable to debug application on-device using Qt-Creator and MADDE (TP2)

[Rudenko Eugene]

Hello, I'm trying to debug on device.I configured all and application compiled and run on device well, but it not stopped on any breakpoints.Qt-creator - 1.3.82 From revision 017ea83680MADDE  - TP2 0.6.14I attached debugger output.I found a couple of strange messages in it: =dATTEMPT BREAKPOINT SYNC<257-break-insert "\"mainwindow.cpp\":33"<258-break-insert "\"main.cpp\":7">&"No source file named mainwindow.cpp.\n">257^error,msg="No source file named mainwindow.cpp."<259break "\"mainwindow.cpp\":33">&"No source file named main.cpp.\n">258^error,msg="No source file named main.cpp."<260break "\"main.cpp\":7">&"break \"\\\"mainwindow.cpp\\\":33\"\n">&"No source file named \\\"mainwindow.cpp\\.\n">~"Breakpoint 1 (\"\\\"mainwindow.cpp\\\":33\") pending.\n">259^done>&"break \"\\\"main.cpp\\\":7\"\n">&"No source file named \\\"main.cpp\\.\n">~"Breakpoint 2 (\"\\\"main.cpp\\\":7\") pending.\n"=It looks like gdb unable to find source codes. How to fix it?Also I got a lot of such errors:==>&"warning: .dynamic section for \"/Users/rule/.madde/0.6.14/sysroots/fremantle-arm-sysroot-2.2009-51-1-qt453/usr/lib/libQtCore.so.4\" is not at the expected address (wrong library or version mismatch?)\n">&"warning: .dynamic section for \"/Users/rule/.madde/0.6.14/sysroots/fremantle-arm-sysroot-2.2009-51-1-qt453/lib/libpthread.so.0\" is not at the expected address (wrong library or version mismatch?)\n">&"warning: .dynamic section for \"/Users/rule/.madde/0.6.14/sysroots/fremantle-arm-sysroot-2.2009-51-1-qt453/usr/lib/libstdc++.so.6\" is not at the expected address (wrong library or version mismatch?)\n">&"warning: .dynamic section for \"/Users/rule/.madde/0.6.14/sysroots/fremantle-arm-sysroot-2.2009-51-1-qt453/lib/libm.so.6\" is not at the expected address\n"===It looks like MADDE's libraries are not match the Device's ones... How to fix itWith best regards Eugene Rudenko.{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf290
{\fonttbl\f0\froman\fcharset0 Times-Roman;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww22440\viewh11420\viewkind0
\deftab720
\pard\pardeftab720\ql\qnatural

\f0\fs24 \cf0 sStarting debugger for tool chain 'GCC for Maemo'...\
dDebugger settings: \
dUseAlternatingRowColours: true  (default: false)\
dUseMessageBoxForSignals: true  (default: true)\
dAutoQuit: false  (default: false)\
dLogTimeStamps: false  (default: false)\
dVerboseLog: false  (default: false)\
dUseDebuggingHelper: true  (default: true)\
dUseCustomDebuggingHelperLocation: false  (default: false)\
dCustomDebuggingHelperLocation:   (default: )\
dDebugDebuggingHelpers: false  (default: false)\
dUseCodeModel: true  (default: true)\
dUseToolTips: true  (default: false)\
dUseToolTipsInLocalsView: false  (default: false)\
dUseToolTipsInBreakpointsView: false  (default: false)\
dUseAddressInBreakpointsView: false  (default: false)\
dUseAddressInStackView: false  (default: false)\
dLocation: gdb  (default: gdb)\
dEnvironment:   (default: )\
dScriptFile:   (default: )\
dWatchdogTimeout: 20  (default: 20)\
dMaximalStackDepth: 20  (default: 20)\
dShowStandardNamespace: true  (default: true)\
dShowQtNamespace: true  (default: true)\
dListSourceFiles: true  (default: false)\
dSkipKnownFrames: true  (default: false)\
dEnableReverseDebugging: false  (default: false)\
dAllPluginBreakpoints: true  (default: true)\
dSelectedPluginBreakpoints: false  (default: false)\
dNoPluginBreakpoints: false  (default: false)\
dSelectedPluginBreakpointsPattern: .*  (default: .*)\
dUsePreciseBreakpoints: false  (default: false)\
dBreakOnThrow: false  (default: false)\
dBreakOnCatch: false  (default: false)\
dChangeLanguageAutomatically: true  (default: true)\
d/Users/rule/development/MAEMO/maemo_test2/maemo_test20x11b4f60\
dState changed from DebuggerNotReady(0) to EngineStarting(1).\
dState changed from EngineStarting(1) to AdapterStarting(2).\
dTRYING TO START ADAPTER\
sNo server start script given. Assuming server runs already.\
dSTARTING GDB /Users/rule/.madde/0.6.14/targets/fremantle-qt-0951/bin/gdb\
dGDB STARTED, INITIALIZING IT\
<238show version\
<239set print static-members off\
<240set breakpoint pending on\
<241set print elements 1\
<242set overload-resolution off\
<243handle SIGSEGV nopass stop print\
<244set unwindonsignal on\
<245set width 0\
<246set height 0\
<247-interpreter-exec console "python execfile('/Applications/Qt Creator.app/Contents/Resources/gdbmacros/dumper.py')"\
<248-interpreter-exec console "python execfile('/Applications/Qt Creator.app/Contents/Resources/gdbmacros/gdbmacros.py')"\
<249-interpreter-exec console "help bb"\
dState changed from AdapterStarting(2) to AdapterStarted(3).\
dADAPTER SUCCESSFULLY STARTED\
sStarting inferior...\
dState changed from AdapterStarted(3) to InferiorStarting(6).\
<250set architecture arm\
<251set sysroot /User