Compiling with Qmake/Make

[Brandybuck]

I'm not sure why I'm replying, as the attitude of the inquirer is decidedly hostile, but here goes:

I am saying that I cannot use qmake + make to build my project, make gives me errors because of qmakes inability to make correct makefiles.

What QMAKESPEC are you using? This is crucial. Let me repeat, this is crucial.

It is an unfortunately fact of development that make was never standardized. Don't blame Trolltech for this. A makefile meant for MS Visual Studio will not work with GNU Make (MinGW, etc). So go check what your QMAKESPEC is. If DevC++ uses GNU Make, then you need to use the win32-g++ QMAKESPEC.

Your points:
* I'd prefer ugly macros that I don't have to deal with than pretty connect functions that require me to use moc every time I need to change slots/signals. Is it really impossible to make it so you don't need moc?

MOC is easy. Get your qmake working and you still stop having problems with moc. Most people never ever touch moc. In fact, I don't remember the last time I ran it manually.

Actually, you don't need moc. If you hate it that much, then don't use it. But that means you have to write the backend dispatch code yourself using QMetaObject. It's like using MFC without the the Visual Studio wizards. It's certainly possible, but very few people are inclined to do so.

You have a button, your library should automatically assign ids to all objects, and then you can have a connect function, just like the qt one, except that when someone uses a custom function, send the function and the class it involves, and then connect the on click WM_COMMAND to the function that was given by connect. It might be hard, but it should be able to be done.

Qt gives you a much more flexible system. You can connect multiple signals to one slot. One signal to multiple slots. Or multiple signals to multiple slots. You can even connect a signal to a signal! It allows you to pass information in a natural way, as custom parameters to your slot. It allows you connect and disconnect objects dynamically at runtime.

No other toolkit offers this amount of flexibility at this cheap of a price. So get your qmake working, and start seeing it for yourself.

[wysota]

Qt gives you a much more flexible system. You can connect multiple signals to one slot. One signal to multiple slots. Or multiple signals to multiple slots. You can even connect a signal to a signal! It allows you to pass information in a natural way, as custom parameters to your slot. It allows you connect and disconnect objects dynamically at runtime.

It even allows you to enumerate methods of a class and call a method by name (meaning not by having a pointer to it, but actually by calling its name - see QMetaObject::invokeMethod) and allows to pass as arguments and retrieve as the result non-standard datatypes. Furthermore it allows you to change properties of object without even knowing their types (on the other hand you can ask for the type) or functions responsible for getting or setting a particular property (enumerating properties is of course also possible so your code can handle custom components it knew nothing about during compilation). The whole concept is very flexible because of its runtime capabilities and in my opinion fully justifies the need to use an additional tool to process the code (especially that it gives means to do it automatically).

[VireX]

I don't know what QMAKESPEC is, all I did was install Qt, and added some environment variables to make sure qmake can see all the libraries/includes. None of this was described in the docs i read, not even the qmake docs. Why don't they write documentation that clearly says what should be done BEFORE trying qmake. I'm hostile because of the amount of information not described to me in the beginner tutorials, and how difficult it is to implement a simple thing like signals/slots... If I hadn't known about the moc procedures, how would any newbie ever get passed the vtable linker errors? i'm sure there are hundreds that gave up just because this was not clearly described.

wysota, stop assuming I am stupid. All I said was "I been programming C++ for years, and I only used Pure Win API rather than graphics libraries. ", which means, i have experience in c++ quite extensively, but i've only been using win API rather than any libraries like Qt. I never said Win API is completely written in C++, because then it would not be compatible with C, so i don't know why you keep feeling the need to teach me that win API is C not C++, it works in both. This is why C++ and C are the same language, because they are, just one is a more updated version with Objects. You're trying to imply that different breeds of dogs are different species. C and C++ are the same language because C++ INCLUDES EVERYTHING C HAS. We're not comparing Java and C++, we're comparing C and C++, they are the same language, so stop arguing semantics with me. Let's also stop the 1 hour-argue-every-point-the-other-guy-makes posts...

When I use mingw32-make, it gives me a few hundred errors, which i cant even scroll up to. But they involve stupid things like vector.tcc: size_type unknown bla bla... and finds compiling errors all over the Qt source itself, basically says QtGUI and QtCore are just bad code... Yes I know I have mingw32 inside devC++ but I also installed it again because wxWidget's designer programs suck A LOT... so i'll uninstall that. I like Qt, which is why even after so many discouraging events, I continue to use it.

I think I'm just not gonna bother with qmake and just use moc manually. THanks for your help, and I apologize for hostility caused by the frustratingly difficult use of signals/slots.

[travlr]

I'm kinda surprised, that a person who's been programming for years, has such an intolerance to frustration.

I'm also kind of surprised at your disdain to those that are taking their own time to try and help you.

I hope you are able to figure it all out,
-travlr

[Brandybuck]

I don't know what QMAKESPEC is, all I did was install Qt, and added some environment variables to make sure qmake can see all the libraries/includes. None of this was described in the docs i read, not even the qmake docs.

You did not read the docs fully. Despite your assertions that this information is not in the docs, I found the necessary information in several spots. Here are two:
http://doc.trolltech.com/4.2/install-win.html
http://doc.trolltech.com/4.2/qmake-e...reference.html

I suppose this information could have been in the very first paragraph of the README file, but putting it in the "Installing Qt/Windows" page is still a fairly easy location to find the necessary information.

However, it is safe to say that most Windows users do not need this information, because most Windows users don't have multiple compilers. When you download and install the Open Source version of Qt, you get MinGW, and the mkspec is set to GNU G++. When you download the commercial version of Qt, you have to choose which compiler. VC++ 6.0, VS 2003 or VS 2005. People typically choose the one that matches their compiler. Thus, it's very rare for people to have this problem. This explains why it isn't prominently mentioned in the README file.

[wysota]

When I use mingw32-make, it gives me a few hundred errors, which i cant even scroll up to.

Redirect output to a file. I can't tell you exact syntax needed for cmd.exe, but the simplest you might try is just "mingw32-make > filename". It depends if make (or maybe rather the compiler) outputs errors to stdout or stderr. If the latter, you need to find out how to redirect stderr to a file (in bash it'd be "make 2> filename").

But they involve stupid things like vector.tcc: size_type unknown bla bla... and finds compiling errors all over the Qt source itself, basically says QtGUI and QtCore are just bad code...

These errors are caused by the compiler trying to recover from previous errors. You always need to see the first error. But in this case we're all pretty sure the problem is with the specs.

As a last resort you might try to install Qt again, it should ask you to point to the mingw compiler (at least I remember so, but I can be mistaken here) so point it to the one you use on a daily basis.

[jacek]

C and C++ are the same language because C++ INCLUDES EVERYTHING C HAS.

This only means that C++ is backwards compatible with C.

But they involve stupid things like vector.tcc: size_type unknown

vector.tcc is a part of STL, not Qt. If you are including any system or STL headers in your sources, try moving appropriate #include directives below those with Qt headers, so that Qt headers are included first, but since you can compile you project manually this probably won't make any difference.

What does "echo %QMAKESPEC%" output? What does "Qt 4.x.y Command Prompt" writes when it starts? Did you try running qmake and make from it?

[VireX]

echo %QMAKESPEC%
%QMAKESPEC%
So it is not set... i guess

As for mingw32-make > filename I had done this weeks ago, it only prints out the makefile, it doesn't print the errorsi nto the file, otherwise i would have posted it...

As far as the comment about frustration, I understand frustration when learning a new language and not knowing how to do certain things, or having some sort of access violation that you can't find in 30,000 lines of code... that I have patience for. I don't have patience for GUI libraries that should have made everything as simple as possible, as OO as possible, to somehow make a simple thing as signals/slots as complicated as they have, especially when you're the one spending 3 hours trying to figure out why qmake doesn't work, or spending days and days posting topics and not being able to fix the problem, or before that, trying to figure out what the hell a linker error like "vtable" etc is... You may think i sound angry/frustrated in my writing, but i'm not really that mad, it's just the way i was typing, because i was slightly annoyed. And the comments/arguments about C++ and C being completely different languages, and I pitty the fool who thinks they are completely different languages. It's clearly the same language, because C++ is backwards compatible, and C++ is an EXTENSION to C, it is not a different language, because most people that know C can easily figure out C++ in a matter of hours... Delphi and C++ are different languages, so stop arguing because you're wrong. This is like saying Age of Empires II, and Age of Empires II: The conquerors are two different games, they are EXPANSIONS, they have completely different things, but they are the same game, so no point in making this circular debate on something you know you're wrong in. Also just cuz i said, "it doesn't work" or "this is crap" or whatever, doesn't mean i'm mad or I think it's worthless...

As far as, me annoying the people trying to help me, in their own time, I greatly appreciate them, but trust me, I have helped thousands of people on other subjects too. But I never insulted them or showed them any disrespect, only debated wysota, which is fun .

[wysota]

echo %QMAKESPEC%
%QMAKESPEC%
So it is not set... i guess

Hmm... if it wasn't set, qmake should complain about it... there is something wrong here.

it only prints out the makefile,

What does it mean?

it doesn't print the errorsi nto the file, otherwise i would have posted it...

You have to redirect stderr then... Maybe even mingw32-make has a commandline option for doing that on its own?

I don't have patience for GUI libraries that should have made everything as simple as possible, as OO as possible, to somehow make a simple thing as signals/slots as complicated as they have

Could you please state what is so complicated and not object oriented?

especially when you're the one spending 3 hours trying to figure out why qmake doesn't work, or spending days and days posting topics and not being able to fix the problem,

I think we told you what's wrong at the very beginning...

or before that, trying to figure out what the hell a linker error like "vtable" etc is...

Hmm... I'm sorry, but if you say you don't know what vtable is, I'm starting to doubt in your understanding of C++.

And the comments/arguments about C++ and C being completely different languages, and I pitty the fool who thinks they are completely different languages. It's clearly the same language, because C++ is backwards compatible, and C++ is an EXTENSION to C, it is not a different language, because most people that know C can easily figure out C++ in a matter of hours... Delphi and C++ are different languages, so stop arguing because you're wrong.

Somehow these arguments don't convince me. C++ is not fully backward compatible with C (type casting, implicit function declarations, implicit return types, probably more) and C++ is definitely not an extension to C (it just evolved from C, it's just like you'd say that crocodile is an extension to a dinosaur). If you want to discuss C++ to be a fully qualified language or not, please contact the author of the language or the comitee responsible for creating standards for the language.

And the argument about C and C++ being the same language because one can easily figure out C++ once knowing C (which is obviously not true in general as it is easier to learn C++ not knowing C) is well.... silly... One can easily figure out javascript once knowing C, because in most cases they have the same (or simmilar) syntax, but I doubt you'd say they are the same language.

And knowing C++ I can easily figure out Python or Java, but I wouldn't consider them the same languages.

Also just cuz i said, "it doesn't work" or "this is crap" or whatever, doesn't mean i'm mad or I think it's worthless...

Try to restrain yourself from using terms that may be considered otherwise then...

As far as, me annoying the people trying to help me

Just for the record, I don't know how about others, but you're not annoying me. I can endlessly continue such discussions also being emotional, but it's the way I am. Just please don't judge tools, architectures or algoritms (or any other methodology) just because you don't understand them or because they don't work as you'd expect them.

[Brandybuck]

Hmm... if it wasn't set, qmake should complain about it... there is something wrong here.

If QMAKESPEC is not set, then qmake will use the default. I believe this is compiled into qmake at build time. The default is whatever qt was built with.

Which brings up an important piece of advice: Always make sure the Qt libs and the QMAKESPEC match. You will run into untold linking problems if you use a win32-g++ QMAKESPEC with a Qt build for win32-msvc. If you are going to be using different compilers, you will undoubtedly need separate Qt installs. The reason is that the C++ ABI is not standardized.

[jacek]

echo %QMAKESPEC%
%QMAKESPEC%
So it is not set... i guess

Then set it to win32-g++. What about that "Qt Command Prompt"?