Hey,
I made the qmake, and then when I do "make" I get:
MAKE version 5.2
Fatal: 'FORCE' does not exist - don't know how to make it
I do not know why this happens.
Printable View
Hey,
I made the qmake, and then when I do "make" I get:
MAKE version 5.2
Fatal: 'FORCE' does not exist - don't know how to make it
I do not know why this happens.
What is the contents of your project (.pro) file?
Code:
Are you running Borland Make?
Does Qt4 (I honestly do not know) support it?
Do you run the Open Source version? If: Could you try "mingw32-make" instead?
This is why I use devC++ to compile and not Qmake/mingw32-make crap, because they never work...
I used mingw32-make instead of make... and it did try and compile, but it gave at least a few thousand errors even though devC++ builds fine except for the moc creating&linking.
You just don't know how to use them properly.Quote:
Originally Posted by VireX
I been programming C++ for years, and I only used Pure Win API rather than graphics libraries. I could have made my own library but that would have taken forever, and wouldn't be as good as Qt... BUTTTTT I would make mine compilable easily with DevC++ and Visual Studio. Rather than force some sort of qmake/make method that never works out. Even if only the Commercial version has VS projects, I would assume someone might have posted their own DevC++ or VS projects. But since I been on this forum, I am under the impression that no one in this forum that has seen my posts has used DevC++ or VC to compile Qt.
If I can't figure out how to use them, then how can someone who barely learned c++ use them? If it's so easy to figure out, why hasn't anyone explained this to me, I been talking about it for basically all the posts I have on this forum. I still have not figured out a single way to use Q_OBJECT/slots without using the moc, or qmake/make, and there is no getting around it, but this means I have to use qmake/make to do it FAST. However, if Qmake and make do not compile a standard pro file that is obviously correctly coded, and I did everything according to what people told me and what the docs tell me, then this means the developers did not test this library enough, or express it correctly in their documents, or no one on this forum knows how to properly explain compiling. Take your pick.
I'm afraid we're starting a flame war, but as I'm the Head-Flame-War-Spawner here then I'll answer anyway :)
WinAPI is C, not C++.Quote:
Originally Posted by VireX
Define "compatible". You don't make a library "compatible" with an IDE but with a compiler and Visual Studio compiler is surely supported. I don't know what DevC++ uses, but I know people are using it with Qt, so I guess it doesn't enforce any broken compilers.Quote:
BUTTTTT I would make mine compilable easily with DevC++ and Visual Studio.
1. Nobody forces you to use either qmake or makeQuote:
Rather than force some sort of qmake/make method that never works out.
2. qmake/make always works for me and furthermore it worked for Windows people I've been working with even if they knew nothing about it and it worked when Visual Studio compilation was failing due to lack of some functionality in the integration plugin or some other problems (I don't know, haven't used the integration).
3. Visual Studio has it's own version of make, which is called nmake and it's a standard tool accompaniating the environment. Of course qmake supports it.
4. Make has been a standard tool for automatic compilation long before Gates even had his garage built.
The reason is simple. If you posted a VS project or DevC++ project, you'd be waiting ages for help, as not everyone has those, whereas qmake is a standard tool shipped with Qt, so you can get your answers in a matter of minutes instead of days. And if you look at the set of good habits of posting here (I think we have such a list somewhere), nobody says you have to post qmake projects and not others. I can always call "qmake -project" and have a working qmake project created from scanning the directory. Sometimes some adjustments may be needed if the files you send need some special treatment.Quote:
Even if only the Commercial version has VS projects, I would assume someone might have posted their own DevC++ or VS projects. But since I been on this forum, I am under the impression that no one in this forum that has seen my posts has used DevC++ or VC to compile Qt.
Maybe you haven't read the qmake tutorial?Quote:
If I can't figure out how to use them, then how can someone who barely learned c++ use them? If it's so easy to figure out, why hasn't anyone explained this to me, I been talking about it for basically all the posts I have on this forum.
As for moc - you have to use it. The reason is simple, it is moc which creates the whole signal/slot implementation for you. You could of course to it by hand, but... well... don't count on our help here, we'll suggest using moc...Quote:
I still have not figured out a single way to use Q_OBJECT/slots without using the moc, or qmake/make, and there is no getting around it,
As for qmake, you can easily call moc by hand, therefore qmake is not needed. It's just a tool that creates a compilation script for you.
Neither qmake nor make do any compilation. Your compiler might be broken or your environment is set incorrectly which confuses qmake about your compiler. Which compiler do you use anyway?Quote:
but this means I have to use qmake/make to do it FAST. However, if Qmake and make do not compile a standard pro file that is obviously correctly coded,
You've been asked to name the compiler in one of the previous posts, but you failed to do this. Without this nobody will be able to help you, we're not trueseers.Quote:
and I did everything according to what people told me and what the docs tell me, then this means the developers did not test this library enough, or express it correctly in their documents, or no one on this forum knows how to properly explain compiling. Take your pick.
I can only say that if you use the Borland compiler, then Qt4 will not work with it, simply because the Borland compiler is so broken, it doesn't conform to any decent and recent C++ standard.
Yay a flame war :P. j/k
"It is designed for use by C/C++ programs and is the most direct way to interact with a Windows system for software applications" taken right out of an article on Win API. So you're wrong, considering I have been using it in my C++ program for years. Hey, maybe you forgot C and C++ are basically the same language, except C++ has OO functionality and a few other things.Quote:
Originally Posted by wysota
Which is why I said Compilable, not compatible. DevC++ uses mingw, so their compiler is supported, and so is VS since the commercial version has project files for it. My point was, that I would make example project files for DevC++ and VS so that people can actually compile without spending hours on settings and other things. It may be compatible with mingw32, but it does not compile with mingw32 unless you use qmake. Because of the Q_OBJECT disadvantage in Qt.Quote:
Originally Posted by wysota
--- Well if I used DevC++ only it won't work with Q_OBJECT unless I manually add stuff after using moc.exe. Since I can only do it manually, the easiest way is to use qmake, which doesn't seem to work, or the documentation is bad, or no one here can explain it. If it was easy, then I wouldn't have had as much trouble as I have. I call it forcing because, it is as if it was made to aggressively encourage you to only use qmake.Quote:
Originally Posted by wysota
-- It works fine, until you decide to use slots signals.Quote:
Originally Posted by wysota
-- Maybe, but I use Visual Studio's build button not nmake.Quote:
Originally Posted by wysota
Maybe so, but why would I use make, when I can just press build and let the program do it for me? Regardless, it doesn't compile, so either qmake is at fault for not setting the settings right, or make doesn't know how to compile qt code.Quote:
Originally Posted by wysota
And I did this, it didn't work. As I told you the error and no one could figure it out. I got a few thousand errors even though compile/build buttons work fine, meaning qmake made a bad project file or make file.Quote:
Originally Posted by wysota
Maybe, but I do not believe I did something wrong, as I explained exactly what I did. Was there a mistake somewhere?Quote:
Originally Posted by wysota
Why do we have to do that though? In wxWidgets, they had event tables, and it didn't require this "extra" step. It wasn't that bad in pure Win API either, I just add stuff to the WM_COMMAND message loop. Why did they make it this way? Was it to make it harder on people, or they just ran out of better ideas or what? IF anything, why isn't there a tool that automatically does this while using DevC++ or Visual Studio. I would assume any newbie like me, that just learns Qt and signals/slots will have this trouble, and switch libraries just because it didn't work, and it wasn't expressed. Luckily I came on this board and found out all about this "moc" thing. It's a hassle, so whatever, that is what I do now, manually use moc. Ok of course there is qmake, so I tried using Qmake only to struggle for hours because mingw32-make will not compile the stuff that qmake created for me. So why won't make work if qmake is tested and perfected? I posted the pro file, doesn't seem wrong to anyone since I heard no objections. So what is your advice now?Quote:
Originally Posted by wysota
qmake is three quick steps:Quote:
Originally Posted by wysota
qmake -project
qmake
make
using moc manually (3 long steps):
Use moc.exe to interpret your files.
copy that code into your main cpp file.
Compile again.
Of course, this could have been even easier if they hadn't required moc, or there was a DevC++ project setting that did all this for me.
Are you sure? make does the compiling, qmake gets the makefile ready. I use mingw32 and DevC++. If make doesn't do compiling, why would it give errors about my files like as if it does compiling?Quote:
Originally Posted by wysota
No one asked me the exact name of the compiler in this post.Quote:
Originally Posted by wysota
I said it was DevC++. Which is common knowledge that it uses mingw32 compiler.
I don't use borland. but if I type make only, a borland make interferes, I don't know how to remove that.Quote:
Originally Posted by wysota
So again I ask, what did i do wrong, I tried using qmake -project, then qmake, then mingw32-make ... what did i do wrong? It compiles fine with DevC++ meaning, qmake has the wrong settings for some reason right?
qmake works fine for me, on Windows, Linux, Mac OSX, FreeBSD and Solaris. It works for me with Visual C++ 6.0, Visual Studio 2005, GNU G++ 3.3 and GNU G++ 4.2. It works for me with GNU Make, BSD make, OSX XCode, Microsoft nmake, Visual Studio 6.0 and 2005 project files. I use Qt professionally in a huge variety of situations with a wide variety of people. It works for me.
Let me ask a few questions to try to narrow this down: You can successfully build a Qt project using qmake, but only with DevC++? You cannot build a Qt project using qmake with MinGW make? You cannot build a Qt project using qmake with Visual Studio, either with nmake or a project file?
Some miscellaneous points:
* The wxWidgets messaging system was heavily influenced by MFC's messaging system. Both require a mess of ugly (imho) macros to create message maps. Qt's signal/slots offer a much more readable, flexible and easy to use system for messaging. It does require you to use a preprocessor (moc), but that is a trivial price to pay.
* Q_OBJECT is necessary for object introspection and signal/slot connect. You cannot choose to forego it just because you don't like it. It is a rare Qt program that doesn't use QObjects. Not using Q_OBJECT or signals/slots with Qt, is like not using message maps with MFC or wxWidgets.
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.
So I use DevC++ to build my projects, I can probably use VS too, but I don't like setting project settings constantly with VS, I use a template file for DevC++, that is easy enough to compile all Qt projects that do not include Q_OBJECT, to use signal/slot/Q_OBJECT I use moc to make an moc file and include it at the bottom of my cpp file. But I prefer to just have some sort of project option that automatically does this for me. Sucks having to remake an moc file everytime I make new slot/signals.
Of course I could try and waste time to make my own templates for VC++ or DevC++, but I don't want to try that. I couldn't find any such files anywhere on the web. In fact, Qt is one of the things that I have never found good sources for except for the trolltech docs themselves, I can't even find simple tutorials for it even, at least ones that had any quality to it.
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?
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.
No, I'm not, it's still a C lib. You can use C libs in C++, you can't use C++ libs in C, therefore WinAPI is C and not C++ as I can write a C app that uses WinAPI.Quote:
Originally Posted by VireX
*basically* and *few other things* are the key words here. They are different languages.Quote:
Hey, maybe you forgot C and C++ are basically the same language, except C++ has OO functionality and a few other things.
Sorry, I might have misread what you wrote.Quote:
Which is why I said Compilable, not compatible.
Q_OBJECT is a macro which expands to some code and additionally serves as a marker for moc to know which classes it should process and for qmake to know which files to call moc for.Quote:
Because of the Q_OBJECT disadvantage in Qt.
Manually? Oh man... can't you just compile the file moc spits out?Quote:
Well if I used DevC++ only it won't work with Q_OBJECT unless I manually add stuff after using moc.exe. Since I can only do it manually,
Here I can agree with you.Quote:
the easiest way is to use qmake,
Here I can't. You're the first person on this forum who complains that "qmake doesn't work".Quote:
which doesn't seem to work,
Did you actually read it or is this just an assumption? AFAIR the docs clearly say what qmake does and why.Quote:
or the documentation is bad,
Ask a specific question and you'll get an answer, either from me or someone else.Quote:
or no one here can explain it.
Actually you can use CMake instead of qmake. It works flawlessly as well, it's just a bit harder to write a working project file, but I'm sure our wiki can help you.Quote:
I call it forcing because, it is as if it was made to aggressively encourage you to only use qmake.
Actually we were using signals and slots quite often. The only problems we had were the ones caused either by VS (I hate the debug and release folders used for the building process), bad habits (non-lowercase file naming) or the Windows platform itself.Quote:
It works fine, until you decide to use slots signals.
Make is exactly such a button, just "pressed" from the cmdline. I'm sure you can configure DevC++ to call "make" to build the project. It will even call qmake for you if the project file is changed.Quote:
Maybe so, but why would I use make, when I can just press build and let the program do it for me?
qmake and make don't compile code... They are both tools which are part of the build process, but it's the compiler that does the compilation. When you call qmake, it generates a Makefile suited for your compiler. Then a call to make will result in the Makefile being processed and one or a series of calls to different tools (compiler, linker or any other tools you find fit) will be made. You can use make to supervise any batch processing where it is possible to judge whether a particular action is required or not based on timestamps (that's basically all make does).Quote:
Regardless, it doesn't compile, so either qmake is at fault for not setting the settings right, or make doesn't know how to compile qt code.
I tend to like to know someone means by "doesn't work" - I can find more accurate solutions then as I don't have to guess and ask for elaborations.Quote:
And I did this, it didn't work.
Oh yes. "Mr Mechanic, my car is broken because the engine doesn't start!"Quote:
As I told you the error and no one could figure it out.
My guess about your problem is that you have a faulty environment - either a wrong compiler takes precedence when qmake is called or something else in the variables is broken. When we started to ask you for specific information, you started calling "craps". So instead of you having resolved your issue we're here talking about qmake.
Did you by any chance think that you might have misconfigured something? I have used that chain and it always worked.Quote:
I got a few thousand errors even though compile/build buttons work fine, meaning qmake made a bad project file or make file.
Obviously there was, as something didn't work :)Quote:
Was there a mistake somewhere?
I suggest you actually take a look at a file moc generates. If you manage to do the same with C preprocessor, I'm sure Trolltech will be interested in buying that solution from you.Quote:
In wxWidgets, they had event tables, and it didn't require this "extra" step. It wasn't that bad in pure Win API either (...) Why did they make it this way?
No, it was to have a fast and error-safe way of implementing object introspection and signals.Quote:
Was it to make it harder on people, or they just ran out of better ideas or what?
There is, it's called make or "visual studio integration" respectively...Quote:
IF anything, why isn't there a tool that automatically does this while using DevC++ or Visual Studio.
Actually you're really the first person complaining about it on this board. There have been complains about qmake but they were caused by its incorrect use and people were satisfied when it was pointed out to them.Quote:
I would assume any newbie like me, that just learns Qt and signals/slots will have this trouble
"moc" stands for "meta-object compiler". Maybe it'll help you understand what it does (a hint - when you don't use meta-objects, you don't need it).Quote:
Luckily I came on this board and found out all about this "moc" thing.
To be honest I think I called moc manually maybe once or twice in my life when I was experimenting with its command line arguments (and now I don't even remember if it has any that make it worth changing the default qmake call, which by the way you can do from within qmake project file, so there is really no reason to call moc by hand).Quote:
It's a hassle, so whatever, that is what I do now, manually use moc.
From what I've seen, you didn't use mingw32-make when starting this thread.Quote:
Ok of course there is qmake, so I tried using Qmake only to struggle for hours because mingw32-make will not compile the stuff that qmake created for me.
Nothing is perfect and qmake complies with that statement. Why doesn't it work? Probably because you are using a port of make which is not compatible with qmake. qmake expects a GNU-make compatible version of make. BSD-make, GNU-make, mingw-make (which is a port of GNU-make) and nmake satisfy that condition. The version of make shipped with MinGW (or MSYS? I don't know, sorry...) doesn't.Quote:
So why won't make work if qmake is tested and perfected?
The project file is correct.Quote:
I posted the pro file, doesn't seem wrong to anyone since I heard no objections.
First stop using the word "crap". Then call your make with "-v" parameter to check what kind of make it is. For example mine returns (among other info) "GNU Make 3.81". Then make sure you're using the version of make that belongs to the mingw32-make package. Then rerun qmake (just in case) and run mingw32-make. If it doesn't work, post the errors and version of qmake and make you used. Then we'll think how to help you further.Quote:
So what is your advice now?
Actually the first step is optional and should be used only once when creating a project.Quote:
qmake is three quick steps:
qmake -project
qmake
make
How about (defines and include paths omitted for clarity):Quote:
using moc manually (3 long steps):
Use moc.exe to interpret your files.
copy that code into your main cpp file.
Compile again.
Code:
Why do you blaim qmake then if your development environment lacks some option? If you don't like it then change it to some other IDE...Quote:
Of course, this could have been even easier if they hadn't required moc, or there was a DevC++ project setting that did all this for me.
Yes, I'm sure. Make is an interpreter for a compilation script. It doesn't modify any file itself.Quote:
Are you sure? make does the compiling, qmake gets the makefile ready.
Because it encounters errors in the script fed to it.Quote:
I use mingw32 and DevC++. If make doesn't do compiling, why would it give errors about my files like as if it does compiling?
You were asked about the version of make used.Quote:
No one asked me the exact name of the compiler in this post.
AFAIK DevC++ is an IDE.Quote:
I said it was DevC++.
It will use whatever you configure it to use.Quote:
Which is common knowledge that it uses mingw32 compiler.
Either delete it from your system, rename it, put it behind mingw-make in the %PATH% (and rename mingw32-make to make) or call mingw32-make explicitely.Quote:
I don't use borland. but if I type make only, a borland make interferes, I don't know how to remove that.
You used an incorrect tool (Borland make) to build your project.Quote:
... what did i do wrong?
It probably calls a correct make version or doesn't use make at all (I think there is a plugin for DevC++ that handles Qt projects).Quote:
It compiles fine with DevC++ meaning,
It is possible, but it's more probable that a wrong make is used. And if qmake settings are indeed wrong, then all that may be wrong is that your toolchain (make) may be guessed incorrectly.Quote:
qmake has the wrong settings for some reason right?
You were telling me Win API is C, like as if it is C exclusive. You acted like as if you didn't know what C++ and C difference is, or you were just trying to act smart by pointing out a very stupid and obvious thing. Of course the library is made in C, so what? It can still be used in C++ which I assumed you didn't know since you made such a stupid comment.Quote:
Originally Posted by wysota
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, but the advantages of C++ are great which is why we use it, they are not different languages at all. That's like calling a person from another country a different race.Quote:
Originally Posted by wysota
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.Quote:
Originally Posted by wysota
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.Quote:
Originally Posted by wysota
I didn't say qmake doesn't work, I said the output of qmake does not work with make, meaning qmake made a wrong output file. Doesn't mean it doesn't work, it means it's buggy.Quote:
Originally Posted by wysota
How else would you explain me following the documentations exactly and then make not working. IF there is an environment mistake as you say, then why doesn't the docs mention this possibility?Quote:
Originally Posted by wysota
I been asking many times, I posted the qt pro file, did it look wrong? 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?Quote:
Originally Posted by wysota
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. But I guess no one has made a project with DevC++ since no one has even mentioned such a capability.Quote:
Originally Posted by wysota
So you never had to use moc or qmake with slots/signals? Then how did you get Q_OBJECT to work?Quote:
Originally Posted by wysota
I don't like opening cmd and finding my directory and using make everytime. I'd rather just compile every time I change code by pressing a button. If you like to waste time, that's your style, not mine.Quote:
Originally Posted by wysota
You contradicted yourself. You jsut said qmake and make don't compile, then you said that make makes a series of calls to the code reader and linker, which is called compiling and building. So obviously after using make, I should have an exe output ... right? Then that means it does compile.Quote:
Originally Posted by wysota
I explained it several times, I get a bunch of errors with make, which I don't get with devC++ meaning qmake generates bad files, since make and devC++ both use same compiler.Quote:
Originally Posted by wysota
So a mechanic would then look inside the car, to see the environment, or in your position ask the person in need of help things that may result in faulty qmake output. Or ask for the makefile, or link to a qmake tutorial, or do something else that's helpful. Guess what, mechanics always get "my car is broken", because that's their job to figure it out, if they knew what was exactly wrong, why would they need the mechanic? If I knew what was wrong, why would I need to post on this forum?Quote:
Originally Posted by wysota
Well I have DevC++ installed. Which has mingw in its bin folder, I have a bunch of files in a project folder, so I used qmake -project, fixed the pro file so that it only includes the files I want to compile, and then typed qmake, then make, and the result was a hundred errors, even though devC++ compiles fine without errors. When you asked for specific information I replied with that specific answer. Scroll up and point out where I have not.Quote:
Originally Posted by wysota
Probably, but then again, if I made a mistake I would assume a hundred others made the same mistake. And I would assume that people in this forum have probably already found a solution to it, since they probably have seen many topics about not being able to compile with qmake. Although I haven't found one while searching this forum.Quote:
Originally Posted by wysota
I guess the people at wxWidgets are just smarter? 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.Quote:
Originally Posted by wysota
Fast would be not using an external program on each of your project files.Quote:
Originally Posted by wysota
Well where is it.Quote:
Originally Posted by wysota
Odd, maybe because the process isn't simple, that I couldn't figure it out after hours and hours of trying even though I have had experience with many compiling problems. Meaning something went wrong. As for the amount of people complaining perhaps, they all faced the same problems and they switched to something else or gave up because they didn't know about this forum, maybe trolltech would be number 1 if they had only made these few things clear, or had a common problems page or something. Or step by step instructions on using qmake properly, or using DevC++ with qt, or VS with Qt.Quote:
Originally Posted by wysota
I knew that, since I had to look it up to know how to use it right? Obviously I have said multiple times that i only use it with Q_OBJECT.Quote:
Originally Posted by wysota
I'm glad your makefiles work out for you. But I have never ever ever compiled successfully with make, even things not involved with qt. That is why I used IDEs that do it for me.Quote:
Originally Posted by wysota
Yes, now I do, because before it said QMAKESPEC error, and the make was borland or something. Now I use mingw32-make, and now i have hundred errors even though my code is 100% correct. Meaning make doesn't know how to read code or is reading wrong files.Quote:
Originally Posted by wysota
I dont know, all I know is I have mingw installed, and because of wxwidgets I have msys installed, and because of devC++ i have mingw installed again in its bin folder, which is the one I usually use.Quote:
Originally Posted by wysota
So why wouldn't make work? Maybe if there was docs that fully explained what make does, and how to use it properly...Quote:
Originally Posted by wysota
Thank you for your helpful advice finally. GNU Make 3.80 is my output. How do I check the mingw32-make package, I thought I just did that?Quote:
Originally Posted by wysota
I'd rather not waste time learning each command line of g++ and let my IDE handle that.Quote:
Originally Posted by wysota
I blame qmake, because there is nothing else to blame. Only when I used qmake did I find the errors, so its either make or qmake's fault. Or maybe its trolltechs fault for not having easy steps to use them properly. My IDE works fine.Quote:
Originally Posted by wysota
OBviously.Quote:
Originally Posted by wysota
But I assumed people knew that DevC++ used mingw32.
Most use it for mingw.. I have never heard of anyone changing the default compiler.Quote:
Originally Posted by wysota
Yeah I'll do that.Quote:
Originally Posted by wysota
No I get errors by using mingw32-make, not using make anymore.Quote:
Originally Posted by wysota
Where? Also I can make it use make, but I dont see the point.Quote:
Originally Posted by wysota
BTW this is the first forum that has such fast session timeouts, like as if there is top secret information here or something.
Look, I answer your questions, but qmake is not working for me, so I'm just gonna use moc manually now...
Can you post first few error messages?Quote:
Originally Posted by VireX
They never had to do this, because MFC and wxWidgets have a static event routing mechanism. They have to know exactly where the event should be directed at the compile time (which also means that you can't change that in the runtime).Quote:
Originally Posted by VireX
Qt has a generic communication mechanism which allows you to establish and remove connections in the runtime, so you don't know a priori what connections will be made, therefore you can't implement this using just a few macros harcoded in your sources.
I can't remember when I had to log in last time, because I've checked the "remember me" check box and I suggest you to do the same. Anyway I have increased the session timeout to 30 minutes.Quote:
Originally Posted by VireX
That's better, at least it isn't crap that doesn't work at all. If we knew something more than "doesn't work" and "gives me errors", we could find the solution.Quote:
Originally Posted by VireX
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.Quote:
Originally Posted by VireX
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.Quote:
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,
No, it's like calling a gorilla and a homo sapiens different species.Quote:
That's like calling a person from another country a different race.
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.Quote:
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.
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.
That's why you have make to do it for you. It's always tedious to do something manually when it can be automated.Quote:
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 was my impression when you called it crap.Quote:
I didn't say qmake doesn't work,
Quote:
I said the output of qmake does not work with make, meaning qmake made a wrong output file...
It doesn't mean anything like that. It only means that make can't understand what qmake outputs.Quote:
meaning qmake generates bad files
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."Quote:
IF there is an environment mistake as you say, then why doesn't the docs mention this possibility?
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.Quote:
I been asking many times, I posted the qt pro file, did it look wrong?
No. It means that devC++ may be calling another copy of make than you call. Did you configure the build environment correctly?Quote:
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?
To have a choice? You're saying that you have to use qmake. I just told you, that you may use CMake instead.Quote:
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.
I didn't say that. I said we didn't have any trouble with qmake. It worked when buttons failed.Quote:
So you never had to use moc or qmake with slots/signals?
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.Quote:
Then how did you get Q_OBJECT to work?
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.Quote:
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.
So maybe you should present them to us?Quote:
I explained it several times, I get a bunch of errors with make,
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?".Quote:
So a mechanic would then look inside the car, to see the environment,
I can bet pretty good money that if you actually made qmake do anything (meaning you set QMAKESPEC correctly), it gave a correct result.Quote:
or in your position ask the person in need of help things that may result in faulty qmake output.
Yes and then he asks "tell me exactly what happened".Quote:
Guess what, mechanics always get "my car is broken",
Knowing what is wrong doesn't mean you know how to fix it.Quote:
if they knew what was exactly wrong, why would they need the mechanic?
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.Quote:
When you asked for specific information I replied with that specific answer. Scroll up and point out where I have not.
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.Quote:
Probably, but then again, if I made a mistake I would assume a hundred others made the same mistake.
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?Quote:
I guess the people at wxWidgets are just smarter?
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".Quote:
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.
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.Quote:
Fast would be not using an external program on each of your project files.
http://doc.trolltech.com/4.2/qmake-manual.htmlQuote:
Or step by step instructions on using qmake properly, or using DevC++ with qt, or VS with Qt.
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.
What did you set QMAKESPEC to? I think in your case it should point to mkspecs/win32-g++ directory in your Qt installation dir.Quote:
Yes, now I do, because before it said QMAKESPEC error, and the make was borland or something.
Which version? What errors?Quote:
Now I use mingw32-make, and now i have hundred errors even though my code is 100% correct.
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.Quote:
I dont know, all I know is I have mingw installed, and because of wxwidgets I have msys installed,
So you have two MinGW installations? Are they in the same version? Maybe they somehow get mixed up?Quote:
and because of devC++ i have mingw installed again in its bin folder, which is the one I usually use.
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.Quote:
So why wouldn't make work?
http://www.gnu.org/software/make/manual/Quote:
Maybe if there was docs that fully explained what make does, and how to use it properly...
We can go through this over and over. The tool is incorrect, not the way you use it.Quote:
Or maybe its trolltechs fault for not having easy steps to use them properly.
So why not stick with it?Quote:
My IDE works fine.
Did you set QMAKESPEC to point to win32-g++ and rerun qmake? What errors do you get?Quote:
No I get errors by using mingw32-make, not using make anymore.
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.Quote:
BTW this is the first forum that has such fast session timeouts, like as if there is top secret information here or something.
I'm not sure why I'm replying, as the attitude of the inquirer is decidedly hostile, but here goes:
What QMAKESPEC are you using? This is crucial. Let me repeat, this is crucial.Quote:
Originally Posted by VireX
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.
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.Quote:
Originally Posted by VireX
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.
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.Quote:
Originally Posted by VireX
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.
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).Quote:
Originally Posted by 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. 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.
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
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:Quote:
Originally Posted by VireX
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.
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").Quote:
Originally Posted by VireX
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.Quote:
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...
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.
This only means that C++ is backwards compatible with C.Quote:
Originally Posted by VireX
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.Quote:
Originally Posted by VireX
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?
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 :).
Hmm... if it wasn't set, qmake should complain about it... there is something wrong here.Quote:
Originally Posted by VireX
What does it mean?Quote:
it only prints out the makefile,
You have to redirect stderr then... Maybe even mingw32-make has a commandline option for doing that on its own?Quote:
it doesn't print the errorsi nto the file, otherwise i would have posted it...
Could you please state what is so complicated and not object oriented?Quote:
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
I think we told you what's wrong at the very beginning...Quote:
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,
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++.Quote:
or before that, trying to figure out what the hell a linker error like "vtable" etc is...
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.Quote:
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.
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.
Try to restrain yourself from using terms that may be considered otherwise then...Quote:
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...
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.Quote:
As far as, me annoying the people trying to help me
Then set it to win32-g++. What about that "Qt Command Prompt"?Quote:
Originally Posted by VireX
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.Quote:
Originally Posted by wysota
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.