Quote Originally Posted by VireX View Post
It can still be used in C++ which I assumed you didn't know since you made such a stupid comment
It is you who brought up WinAPI. WinAPI has nothing to do with C++, that was my point. If I were to be picky I'd say that WinAPI contains graphical routines as well, but I didn't.

The only differences between C and C++ are Classes and OOP extensions. Templates, stronger typing, and a bigger standard library. So they are basically the same language,
The difference between C and Objective C is that the latter has objects, but I think noone sane would call them the same language... For me when you need to use a different approach when programming in two languages, they are different. And according to this, C and C++ are completely different.

That's like calling a person from another country a different race.
No, it's like calling a gorilla and a homo sapiens different species.

Yes obviously. I never said I didn't know what it is, I said that if wxWidgets can make macros without "moc" then Qt should be able to do it too.
Moc uses the macro as a marker, it doesn't do any magic with it. Q_OBJECT gets expanded by the C preprocessor, just like all other macros.

And you don't have to use Q_OBJECT in your applications. If you don't need new signals/slots and don't have a need to extend a class with introspection abilities, you can omit it. Furthermore you can use signal implementation from Boost library.

Yes it is what i do, but it's awful to remake the moc everytime you wanna test a new slot or changed your program for better slots.
That's why you have make to do it for you. It's always tedious to do something manually when it can be automated.

I didn't say qmake doesn't work,
That was my impression when you called it crap.

I said the output of qmake does not work with make, meaning qmake made a wrong output file...
meaning qmake generates bad files
It doesn't mean anything like that. It only means that make can't understand what qmake outputs.

IF there is an environment mistake as you say, then why doesn't the docs mention this possibility?
Probably because they can't cover every possible situation. Trolltech explicitely states that Borland tools are not supported in Qt4, so I don't see a point having an additional paragraph "When you call make, be sure not to be calling Borland make as it will not work. Furthermore if you implement your own make port, it might not work as well, especially if you don't implement functions GNU make usually has."

I been asking many times, I posted the qt pro file, did it look wrong?
As I already said, the project file is fine. The output from qmake is also probably fine. The problem is probably with make, not with qmake.

I used mingw32-make as someone mentioned, if mingw32 in devC++ works, but mingw32-make doesn't work, doesn't that mean the makefile generated by qmake is faulty?
No. It means that devC++ may be calling another copy of make than you call. Did you configure the build environment correctly?

Why waste my time to learn another program, when I can make a project file for DevC++ and use it every time, that automatically adds the moc stuff that is needed.
To have a choice? You're saying that you have to use qmake. I just told you, that you may use CMake instead.

So you never had to use moc or qmake with slots/signals?
I didn't say that. I said we didn't have any trouble with qmake. It worked when buttons failed.

Then how did you get Q_OBJECT to work?
Q_OBJECT doesn't "work". Q_OBJECT will get expanded regardless if you use qmake/moc or not. Moc does things like calculating method numbers, provides meta-data for the class, etc.

You jsut said qmake and make don't compile (...) So obviously after using make, I should have an exe output ... right? Then that means it does compile.
I said make is used to build the application and it's exactly what it does. It doesn't do anything with the program source on its own, so it doesn't compile. It's exactly the same when I say that the compiler doesn't link your app. It calls the linker to do it.

I explained it several times, I get a bunch of errors with make,
So maybe you should present them to us?

So a mechanic would then look inside the car, to see the environment,
Yes and after taking the engine apart he'd ask "What happened when you turned the key to start the engine?" and get a response "Oh, you have to turn the key?".

or in your position ask the person in need of help things that may result in faulty qmake output.
I can bet pretty good money that if you actually made qmake do anything (meaning you set QMAKESPEC correctly), it gave a correct result.

Guess what, mechanics always get "my car is broken",
Yes and then he asks "tell me exactly what happened".

if they knew what was exactly wrong, why would they need the mechanic?
Knowing what is wrong doesn't mean you know how to fix it.

When you asked for specific information I replied with that specific answer. Scroll up and point out where I have not.
Only a post ago you confirmed to have Borland make installed in your system and it was asked on the very beginning of this thread.

Probably, but then again, if I made a mistake I would assume a hundred others made the same mistake.
I think there have been topics about make failing either here or on QtForum (or both). The reason was most often MSYS or incorrect make being used. That's exactly the case here.

I guess the people at wxWidgets are just smarter?
Maybe they are. Does wxWidgets have a meta-object system? Could you tell me exactly on how many platforms does wxWidgets work? Does it work on embedded devices?

I saw what moc generates, it makes it so that the connection is established between objects, but somehow wxWidgets never had to do this, I wonder why.
Then look again. Moc is not only about signals and slots. To be honest it's just a side effect of object introspection. That's why I told you what "moc" actually means. It's not called "ssc" or "sasc" or "pitaa" but "moc".

Fast would be not using an external program on each of your project files.
Fast during execution, not compilation (you compile once, execute multiple times). You have to admit comparing integers is much faster than parsing and comparing strings.

Or step by step instructions on using qmake properly, or using DevC++ with qt, or VS with Qt.
http://doc.trolltech.com/4.2/qmake-manual.html
http://doc.trolltech.com/4.2/tutorial-t1.html

I don't use DevC++ so I can't give you a link. But I think there is a tutorial about it somewhere. VS Integration surely comes with a manual.

Yes, now I do, because before it said QMAKESPEC error, and the make was borland or something.
What did you set QMAKESPEC to? I think in your case it should point to mkspecs/win32-g++ directory in your Qt installation dir.

Now I use mingw32-make, and now i have hundred errors even though my code is 100% correct.
Which version? What errors?

I dont know, all I know is I have mingw installed, and because of wxwidgets I have msys installed,
Don't use MSYS with Qt. mingw32-make inside MSYS doesn't know how to handle paths generated by qmake. Trolltech has prepared a solution for that so since 4.3 you're able to compile from inside MSYS as well.

and because of devC++ i have mingw installed again in its bin folder, which is the one I usually use.
So you have two MinGW installations? Are they in the same version? Maybe they somehow get mixed up?

So why wouldn't make work?
qmake relies on some features which are not implemented with all ports of make - you have to use make that is compatible with GNU make. Period. Having workarounds for all possible configurations was too expensive for Trolltech - after all, they are to write code, not to produce workarounds for faulty tools.

Maybe if there was docs that fully explained what make does, and how to use it properly...
http://www.gnu.org/software/make/manual/


Or maybe its trolltechs fault for not having easy steps to use them properly.
We can go through this over and over. The tool is incorrect, not the way you use it.

My IDE works fine.
So why not stick with it?

No I get errors by using mingw32-make, not using make anymore.
Did you set QMAKESPEC to point to win32-g++ and rerun qmake? What errors do you get?

BTW this is the first forum that has such fast session timeouts, like as if there is top secret information here or something.
Sorry for that, I think Jacek just corrected it. Just please don't start blaiming the forum now We're currently using most time to answer questions, not to maintain the software. There is no top secret information here and you can view all the content even if not logged in, so you're just being picky.