- Status Closed
- Percent Complete
- Task Type Bug Report
- Category QCAD (main)
-
Assigned To
Andrew - Operating System All
- Severity Low
- Priority Very Low
- Reported Version 3.5.1
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: QCAD Bugtracker
Opened by Tamas TEVESZ - 16.05.2014
Last edited by Andrew - 21.05.2014
Opened by Tamas TEVESZ - 16.05.2014
Last edited by Andrew - 21.05.2014
FS#1050 - Compilation error under Linux / X11 (c60189 build failure)
This has been in for a couple of revisions now
RS.cpp: In static member function ‘static bool RS::compare(const QVariant&, const QVariant&)’: RS.cpp:204:30: error: expected unqualified-id before ‘int’ if (v1.type()==QVariant::Bool && v2.type()==QVariant::Bool) { ^ RS.cpp:204:30: error: expected ‘)’ before ‘int’
g++ 4.8.1, Qt 4.8.4, Ubuntu 12.10.
Closed by Andrew
21.05.2014 14:56
Reason for closing: Fixed
Additional comments about closing:
21.05.2014 14:56
Reason for closing: Fixed
Additional comments about closing:
https://github.com/qcad/qcad/commit /a22bc0ecb4f3a6b6a8d7a76ac26cd5d3ea1182c 4
I'm unable to reproduce this at the moment, nor can I spot the problem in the code you've posted. Any ideas?
Clang on FreeBSD was a bit more helpful.
Not yet sure what to make of it or even how/when did it creep in, I see no obvious change anywhere that could have affected this.
Running bisect now, it will take a while.
This might help (similar problem with Xlib.h and Qt):
http://comments.gmane.org/gmane.comp.kde.devel.core/18665
Uhm, I see now.
It seems there's a lot of clash between Qt and Xlib stuff, and I'm not sure shuffling headers around is a good way out. How about breaking up RS.cpp a bit? It seems that some of it is platform-dependant stuff, some of it (RS::compare) is some QCAD-helper function that is not platform-dependant.
Apart from these ::compare() stuff, the others are just strings and ints, hopefully by separating them (and thus simplifying the headers needed in each case) the chance of clashing would reduce.
What do you think?
Breaking up 'RS.cpp' into 'RS.cpp' and 'RSPlatform.cpp' or similar is fine with me.
RS.h should not be split since that would break includes as well as the automatic script wrapper generation.
PS: does including fixx11h.h not help?
It does (seemingly – still running, past that point already, though), but I see problems with that.
fixx11h.h is part of kdelibs-dev, which means either KDE will become a build dependency, or a private copy of fixx1h.h has to be included in QCAD. The first option is pretty much a no go I think :), the second is viable (it's ISC-licensed).
I still don't think that should be viewed as a permanent solution, unless the splitting of RS.cpp fails for whatever reason, because if splitting succeeds, that's as clean a solution as it can be, while fixx11h.h will always be just sedating the worms in the can.
I also don't understand how does that not surface in your builds? :)