Qt #define "signals" clashes with GStreamer (gst)

Question

Qt, which seems to name everything else with an initial Q, does this: #define signals signals in qobjectdefs.h.

However, GStream, not naturally, does not imagine signals to be a reserved word and does this

struct _GDBusInterfaceInfo
{
  /*< public >*/
  volatile gint         ref_count;
  gchar                *name;
  GDBusMethodInfo     **methods;
  GDBusSignalInfo     **signals;         <==================
  GDBusPropertyInfo   **properties;
  GDBusAnnotationInfo **annotations;
};

in gdbusintrospection.h.

Am I just to assume that Qt and GStreamer don't play well together., or is there a way around this?

Note: Qt can be persuaded to #define signals signals if I don't #define Q_MOC_RUN. But that leads to problems with classes which are using

class
{
   public:
      // stuff
   signals:
      // stuff
   private:
      // stuff
};

As you might have guessed by now, I am trying to take over code from someone who is not around to support it and Google is not my friend:-(

[Update] Thanks, @IpApp fro the tip (which is not working, alas).

I have been given someone else's code. Apparently it build for target, but has never been built for unit test and I have to do that (why he mix & matched, I do not know).

When I use QT_NO_KEYWORDS in Eclipse CDT, I get errors because the class definition code does not use Q_SINGAL(S) - it uses the signals macro (which is now defined as signals) to define certain public members.

I am not allowed to alter the subsytsem code, just to mock its interfaces, but I am loathe to mock all of Qt & Glib, because of the effort.

Perhaps there is a way to use libraries for one or the other, rather than including their directories into the source path?

"Perhaps there is a way to use libraries for one or the other, rather than including their directories into the source path?" Well, yes, you should always ensure that each compile target is only given the library paths it actually needs....or is that not what you're asking? — Kyle Strand, Dec 28 '15 at 00:05

score 4 · Accepted Answer · answered Dec 17 '14 at 12:36

4

Just follow this documentation in your qmake project file:

CONFIG += no_keywords

If you are using something else than qmake, make sure that you define the following in your buildsystem:

QT_NO_KEYWORDS

Then, you need to make sure that you use Q_SIGNALS or Q_SIGNAL all over the place in your headers so that moc (meta object compiler) is still notified that it is a signal.

answered Dec 17 '14 at 12:36

László Papp

51,870
39
111
135

1

Note: it is another question why you use gstreamer directly and not QtMultimedia. – László Papp Dec 17 '14 at 13:05
Please see updated question, as there is not enough room in this comment to reply. – Mawg says reinstate Monica Dec 17 '14 at 14:44
1

@Mawg: can you do `#undef signals` before including `gdbusintrospection.h` or that is also out question? – László Papp Dec 17 '14 at 14:49
I am afraid that I cannot. I have to use the code as-is. I am still trying to understand how it builds for the target, but no one can help me. – Mawg says reinstate Monica Dec 18 '14 at 09:40
@Mawg: why? If you have the source code, you can surely patch it like the distributions do on Linux with broken upstream software? – László Papp Dec 18 '14 at 09:42
1

@Mawg: also, what functionality do you plan to use from gstreamer? Have you considered using QtMultimedia instead if possible? – László Papp Dec 18 '14 at 14:52
I am sorry, but I am unable to change a single line of code. What already is - is. I can only mock the externals. As I said, I would prefer not to mock Qt or Gst, but I cannot see how to compatibly compile them. Thanks fr all of your help so far. – Mawg says reinstate Monica Dec 18 '14 at 19:48
1

@Mawg: I really do not get you. You have the source code as you are building from source, so why cannot you fix the broken code? There is no way around to it, unless you want to drop gstreamer, which you probably should in favor of QtMultimedia, but that is a bigger undertake than fixing a few keywords. – László Papp Dec 18 '14 at 23:52
Because I have to unit test in Linux the identical code which somehow builds as part of a complete system for ARM. I am not allowed to change a line of production code (else what am I testing?), but I can remove the neighbouring subsystems and mock them. The code is not broken on ARM, I just can't recreate the build environment for Linux :-( Also, I cannot drop Gstreamer. My only option seems to be to mock either Qt or GStreamer since I cannot figure out how to use them together in Linux. – Mawg says reinstate Monica Dec 19 '14 at 12:05
2

If it is not broken for ARM, then your question does not make much sense, I am afraid. Then, the issue is simply already solved, so what are you asking then about at all? This has nothing to do with mocking. – László Papp Dec 19 '14 at 12:07
2

@Mawg: what do you expect us to tell you here if you have broken code, but you do not wanna fix it, or as the example shows, perhaps the code is not broken, you are just unaware of how to build it properly as the original author has not given you enough information? – László Papp Dec 19 '14 at 15:40
I guess I wasn't explaining well enough. The entire system, including Qt and GStreamer, build for ARM. I want to build only a single subsystem on Linux, mocking the rest. I had thought to mock only our code using the real Qt and GStreamer. Since I can't resolve this problem, I will mock Gstreamer & use the real Qt. – Mawg says reinstate Monica Dec 21 '14 at 09:24
@Mawg That is almost certainly not the right solution. You have a build problem that you should resolve. There is *nothing* special about ARM that would alter macro expansion. (Also, ARM is an architecture, not an OS; Linux can run on ARM, so it's not clear what you're getting at by contrasting ARM with Linux.) Try comparing the exact compile commands used to compile a particular target that currently can't be compiled for Linux between your two different build targets. – Kyle Strand Dec 28 '15 at 00:10
Also, if you can't change the code, what will you do when a unit test fails? – Kyle Strand Dec 28 '15 at 00:11

score 1 · Answer 2 · answered Dec 27 '15 at 23:58

1

I have found another solution which as for me is more convenient and simple - you should include glib headers before Qt headers, and thats all. As glib code goes before, it is unaffected by Qt define statements.

answered Dec 27 '15 at 23:58

locomotion

1,568
3
11
16

score 1 · Answer 3 · answered May 03 '23 at 09:07

1

From QT documentation:

define QT_NO_SIGNALS_SLOTS_KEYWORDS
replace slots by Q_SLOTS, signals by Q_SIGNALS

answered May 03 '23 at 09:07

lfk

57
7

Qt #define "signals" clashes with GStreamer (gst)

3 Answers3