@alfkil Well, like you said its the wrong thread but if you want to get involved you have all info in the url. I m retarded when it comes to this but spotup asked me to try and i dont want to give up that easily When i type gmake i get an error like the one in the thread.
Ok, some notes (apparently these are general problem, so I will add some notes to the Qt SDK readme in the next version):
1) In the following files in the native SDK, the keyword "signals" needs to be replaced with "_signals" (this is because "signals" is reserved for special use by Qt):
1) In the following files in the native SDK, the keyword "signals" needs to be replaced with "_signals" (this is because "signals" is reserved for special use by Qt):
I don't consider changing a few parameter names "hacking", it is just a way of avoiding a much bigger problem. The keyword "signals" in Qt is so widely used and is so central to Qt's inner workings, that it would be stupid to try and "fix the problem" in Qt. And this is NOT "the occasional source", this is EVERY Qt program...
Btw, for all my expirience with ports, i notice how it sometime annoing to change the same keywoard (not in QT , but i mean in general). For example, very offten game use words EventHandler, or different kind of typedefs for int32/chars/etc, or very offten they use Screen, Window. And sometime its just a nightmare to change manually everything in the code (i mostly trying to not touch SDK, just because once it changes, then its forgotten, and SDK kind of broken forever , until you not remember what you do and why).
So, by all of this i am almost sure that GCC should have some kind of easy workoround for such kind of problems. Maybe some small redefines in "config.h" can make a deal, or some magic flag .. Maybe you have any ideas or expirience about ?
I think I have solved most of those annoying issues, as a matter of fact: Qt uses "private" classes to do all the internal (platform specific) work, which means, that if I keep the "public" class definitions clean of system includes, most of those names ("Window", "Screen", "Image" etc) can now be used in apps with no problems.
I don't consider changing a few parameter names "hacking", it is just a way of avoiding a much bigger problem. The keyword "signals" in Qt is so widely used and is so central to Qt's inner workings, that it would be stupid to try and "fix the problem" in Qt. And this is NOT "the occasional source", this is EVERY Qt program...
It's only a little hack perhaps but it's still a hack, if each porter / developer added their own little hack, the SDK would end up amess with no one being able to build anyone elses source.
Looking at the lines in question these all appear to be variable names.
The solution then would be to ensure that the SDK includes containing these prototypes were included first before any Qt include.
What is "signals" for Qt anyway? A type ? A define?
How am I supposed to deal with the fact, that Qt needs to be able to replace (by normal pre-processing, NOT by moc) instances of "signals" with "protected"?
Really, just changing those few places in the SDK is no big deal, it doesn't change anything... C'mon!...
How am I supposed to deal with the fact, that Qt needs to be able to replace (by normal pre-processing, NOT by moc) instances of "signals" with "protected"?
Really, just changing those few places in the SDK is no big deal, it doesn't change anything... C'mon!...
But it's not just the SDK anyway it would be any third party libray that happend to have a function of variable called signals.
test.cpp
int myfunc(int signals);
#define signals protected
class someclass {
signals:
void myprotectedmethod();
}
The problem is, that Q_WS_AMIGA is defined in a Qt header, so I need to include that first. Hence not possible to include first AMIGA then Qt...
Now, the problem might have been solved with regards to Qt apps (that is apps that use Qt as opposed to Qt itself), so that AmigaOS includes are in fact never included in the code (unless someone would need to access the OS inside the code, which would then be a problem). So the only thing that remains is the actual building of Qt libraries themselves, which is mainly done by me, and I hereby grant myself right to "fix" the SDK in the named places!
Btw: Quote:
But it's not just the SDK anyway it would be any third party libray that happend to have a function of variable called signals.
This is the same on all platforms, though, not just AmigaOS. The morale is, if you plan to use your code (library etc.) together with Qt, you cannot use "signals" as a variable name.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
When i type gmake i get an error like the one in the thread.
