Qt Creator and other tools

Thank you.

Creator is just one of several platforms. It's an IDE, and does not offer a replacement for a true build process.

And BTW, the mistake was a stupid one: I put the line
@CONFIG += debug@
at a central position into a central .pri file, and forgot about it.

What set me on the wrong track that I could still build release versions under Windows.

[quote author="danimo" date="1323945384"]qmake's make install rule uses the INSTALL_ROOT prefix by default, so you need

make install INSTALL_ROOT=/home/luca/qtcreator

it will put /lib /bin and /share underneath (in your case, it should actually try to install all three, but to the root directory).[/quote]

Thanks, it Works!

That does indeed sound interesting. I would love to have something like that as part of the Qt Creator documentation, but am not sure it is OK to include something you describe as a "rewrite of two sections of Blanchette and Summerfield".

Maybe you could get into contact with them and have them include it in a new copy of their work? Or -- if you consider your work to be derived and the original authors agree -- you could integrate it into the Qt Creator documentation found next to the sources in "the repository":https://qt.gitorious.org/qt-creator and send your change for review via "gerrit":http://codereview.qt-project.org/.

Thanks, that's nice to know I wasn't screwing something up for a change.

[quote author="Tobias Hunger" date="1323856019"]I recommend taking a look into the documentation by the way.[/quote]
Hello, Tobias,

well, I did that, even before asking. Seems I've been trapped by the there mentioned "local repositries", as I hold a repo on my local disk.

But, finally, I got it working on Windows7 with the following steps:

A well installed VisualSVN-Server;
A well installed TourtoiseSVN;
and of course a properly installed Qt SDK 1.1.4.

After creating a project with Qt Creator you can import it's directory structure into the svn repo.
Then close it in Qt Creator, and get it back via File->New...->Get from VCS repository.

The project files in the working folder will be overwritten, but... who cares? ;)

Thanks for your advise!

regards
Joerg

Don't you try logic on me!

Joking, sorry ;) Of course, you are correct. Not everybody would have to be a contributor, in fact. To keep number of commits down, they could be performed by less people than the number of those finding "bugs" in documentation. And to be honest, I did mean contributors devising new features.

Aaaanyway, just theorising, cause I'm in a kind of "Friday" mood. An idea that might catch some momentum and do some good, or - most probably - wither and die miserably in darkness of the past.

I was able to get my code to work after realizing that the slots for the Widgets that I removed were being declared in my .h file which would explain why they were getting re-created in the moc*.cpp file.

I removed them from my .h file and everything appears to be working correctly, now.

I still don't see anything in the Signals & Slots Editor for any of my Widgets, but I can at least continue working on my tests.

Thanks for the quick reply.

it's the C++ code autocompletion feature but the application compiles properly.

or maybe is there a way to reset ALL the settings back to default in case I messed something up? thank you very much again :)

In that case I suggest you open the updater again and make sure it is selected.

The problem was that the debugging helpers had not bee built. I've put a link to where I found the solution.

Link:

https://bugreports.qt.nokia.com/browse/QTSDK-1047

Ok, I'll run the configure.exe.

PS: Thanks a lot for your help.

That's quite simple: $${XYZ} will be replaced by the contents of variable XYZ. It can be any of the predefined variables/constants of qmake or a self defined variable. I've added the quotes because my target can contain spaces and the script would interpret it as two arguments in that case. On the shell command line you would call it like this:

@
./OSX-lib-and-framework-paths.sh "My Application.app"
@

The TARGET variable contains the base name of your final binaray. The complete file name depends on the target type as well as the operating system and is "calculated" for the respective uses. For example:

application on Windows: target.exe static lib on Windows: target.lib dynamic lib on Windows: target.dll application on OS X: target.app static lib on OS X: target.a dynamic lib on OS X: target.dylib application on Linux: target (no suffix) static lib on Linux: target.a dynamic lib on Linux: target.so

The TARGET variable does not contain the path to the final binary. You should be able to construct that together with the DESTDIR variable, though.

General info on the variable voodoo can be found in the "variable documentation":http://developer.qt.nokia.com/doc/qt-4.7/qmake-advanced-usage.html of the qmake manual. In general, it's a good idea to read that from the very beginning to the end :-)

I resolved the problem.
the g++ compiler was not installed, gcc was.
After installing g++ QtCreator start to open projects normally.

I think this is the bug in QtCreator.
They should add g++ to dependences or change subj error message to more correctly one.

Just had to reinstall the Qt version that was causing the problem, using the SDK maintenance tool. Now it's using the corresponding Windows tools instead, and everything works just fine!

@Bradley: Agreed, RPATH can be used for development as well. It is probably more of a gut reaction to not "abuse it" for development.

@ludde: Setting LD_LIBRARY_PATH and PATH and DYLD_LIBRARY_PATH (and whatnot :-) ) is what I am doing as a workaround. Thanks for the pointer to the Qt Creator thread.

I will check with the Qt Creator guys if automatically setting the library path for debugging is supposed to work. If so, I guess the current behavior is simply a bug. Thanks!