Download QCAD

← All bug reports

FS#1050Compilation error under Linux / X11 (c60189 build failure)

Type
Bug
Status
Closed
Resolution
Fixed
Category
QCAD (main)
Severity
Low
Priority
Low
Reported version
3.5.1
Operating system
All
Reported
2014-05-16 by kazmer
Closed
2014-05-21 by andrew

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.

Comments (7)

andrew 2014-05-19

I'm unable to reproduce this at the moment, nor can I spot the problem in the code you've posted. Any ideas?

kazmer 2014-05-21

Clang on FreeBSD was a bit more helpful.

RS.cpp:204:30: error: expected unqualified-id
    if (v1.type()==QVariant::Bool && v2.type()==QVariant::Bool) {
                             ^
/usr/local/include/X11/Xlib.h:94:14: note: expanded from macro 'Bool'
#define Bool int
             ^

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.

kazmer 2014-05-21

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?

andrew 2014-05-21

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.

andrew 2014-05-21

PS: does including fixx11h.h not help?

kazmer 2014-05-21

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? :)

Closure comment

https://github.com/qcad/qcad/commit/a22bc0ecb4f3a6b6a8d7a76ac26cd5d3ea1182c4