Re: [Development] moc 4.8.6 macros

2014-09-17 Thread Thiago Macieira
On Tuesday 16 September 2014 23:00:06 Samuel Gaist wrote:
 Good question, I'll have to check. 
 If that where not the case, what should I write to give additional include
 paths to moc ?

Replace QT_DEPRECATED_SINCE with the actual contents of the macro. Also expand 
QT_VERSION_CHECK.

Qt 4 moc does not expand macros.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-17 Thread Olivier Goffart
On Tuesday 16 September 2014 23:52:36 Thiago Macieira wrote:
 On Tuesday 16 September 2014 23:00:06 Samuel Gaist wrote:
  Good question, I'll have to check.
  If that where not the case, what should I write to give additional include
  paths to moc ?
 
 Replace QT_DEPRECATED_SINCE with the actual contents of the macro. Also
 expand QT_VERSION_CHECK.
 
 Qt 4 moc does not expand macros.

Qt 4 moc does expand macros in #if directive.

(and QT_DEPRECATED_SINCE is defined to 1 for Qt4 in qtserialportglobal.h)

-- 
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-17 Thread Samuel Gaist

On 17 sept. 2014, at 17:20, Olivier Goffart oliv...@woboq.com wrote:

 On Tuesday 16 September 2014 23:52:36 Thiago Macieira wrote:
 On Tuesday 16 September 2014 23:00:06 Samuel Gaist wrote:
 Good question, I'll have to check.
 If that where not the case, what should I write to give additional include
 paths to moc ?
 
 Replace QT_DEPRECATED_SINCE with the actual contents of the macro. Also
 expand QT_VERSION_CHECK.
 
 Qt 4 moc does not expand macros.
 
 Qt 4 moc does expand macros in #if directive.
 
 (and QT_DEPRECATED_SINCE is defined to 1 for Qt4 in qtserialportglobal.h)
 

Indeed it's defined, but it looks like moc doesn't handle the case when the 
macro has one or more parameter(s) even if defined in the same file

Samuel

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-17 Thread Thiago Macieira
On Wednesday 17 September 2014 17:42:40 Samuel Gaist wrote:
 On 17 sept. 2014, at 17:20, Olivier Goffart oliv...@woboq.com wrote:
  On Tuesday 16 September 2014 23:52:36 Thiago Macieira wrote:
  On Tuesday 16 September 2014 23:00:06 Samuel Gaist wrote:
  Good question, I'll have to check.
  If that where not the case, what should I write to give additional
  include
  paths to moc ?
  
  Replace QT_DEPRECATED_SINCE with the actual contents of the macro. Also
  expand QT_VERSION_CHECK.
  
  Qt 4 moc does not expand macros.
  
  Qt 4 moc does expand macros in #if directive.
  
  (and QT_DEPRECATED_SINCE is defined to 1 for Qt4 in qtserialportglobal.h)
 
 Indeed it's defined, but it looks like moc doesn't handle the case when the
 macro has one or more parameter(s) even if defined in the same file

Right, so let me be clearer: moc in Qt 4 does not expand macro calls.

$ cat foo.cpp
#define FOO(x) x
#if FOO(1)
class Foo : public QObject { Q_OBJECT };
#endif

$ moc -qt4.8 foo.cpp  /dev/null
foo.cpp:0: Note: No relevant classes found. No output generated.

$ moc -qt5 foo.cpp  /dev/null

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-16 Thread Samuel Gaist

On 12 sept. 2014, at 11:14, Olivier Goffart oliv...@woboq.com wrote:

 On Thursday 11 September 2014 22:03:03 Samuel Gaist wrote:
 On 11 sept. 2014, at 21:49, Thiago Macieira thiago.macie...@intel.com 
 wrote:
 On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote:
 What would be the correct procedure to handle QT_DEPRECATED_SINCE ?
 Removing it from around the signal declaration would make the code a bit
 inconsistent.
 
 By the way, how is it handled in Qt 5 since building goes without any
 problem even with the macros around the signal ?
 
 moc is smarter in Qt 5: it expands macros.
 
 But the recommendation stands: do not #if (of any kind) anything that
 isn't
 #defined in the same source, in a header next to the one being compiled,
 or
 passed as -D in the command-line.
 
 That means: don't hide signals and slots with #if, even for deprecation.
 
 I thought I've read somewhere that moc got better at this job :-)
 
 I would not be as strict as Thiago.  
 In Qt5 it's fine to use the preprocessor as long as moc can see the defines 
 (that is, if they don't rely on compiler built-in or need special include 
 paths.)
 QT_DEPRECATED_SINCE should be fine.
 
 It is strange it does not work with Qt4.  Are you sure that all the include 
 paths are passed to moc?

Good question, I'll have to check. 
If that where not the case, what should I write to give additional include 
paths to moc ?

 Otherwise, you will have to work around it somehow.
 try #if not QT_DEPRECATED_SINCE() #else
 Or some other trick with Q_MOC_RUN

I forgot about that one, might be a starting point

 
 You can also use the QT_MOC_COMPAT macro in front of a declaration so QObject 
 will throw a runtime warning when connecting to this signal. (in debug mode)

Good to know

 
 It seems that the new moc doesn't use much of the Qt 5 only classes, would
 it be useful to backport it to Qt 4 to avoid having to break the code
 style for modules supporting both series ?
 
 This is out of question.
 This is a behaviour change as Qt4 code relied on moc not expending the macro 
 in some cases.
 
 (At some point it will be time to switch fully to Qt5 and drop Qt4 support)

I agree, but there are still lots of people locked to Qt 4… There's even posts 
on the forum asking for Qt 3


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-12 Thread Olivier Goffart
On Thursday 11 September 2014 22:03:03 Samuel Gaist wrote:
 On 11 sept. 2014, at 21:49, Thiago Macieira thiago.macie...@intel.com 
wrote:
  On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote:
  What would be the correct procedure to handle QT_DEPRECATED_SINCE ?
  Removing it from around the signal declaration would make the code a bit
  inconsistent.
  
  By the way, how is it handled in Qt 5 since building goes without any
  problem even with the macros around the signal ?
  
  moc is smarter in Qt 5: it expands macros.
  
  But the recommendation stands: do not #if (of any kind) anything that
  isn't
  #defined in the same source, in a header next to the one being compiled,
  or
  passed as -D in the command-line.
  
  That means: don't hide signals and slots with #if, even for deprecation.
 
 I thought I've read somewhere that moc got better at this job :-)

I would not be as strict as Thiago.  
In Qt5 it's fine to use the preprocessor as long as moc can see the defines 
(that is, if they don't rely on compiler built-in or need special include 
paths.)
QT_DEPRECATED_SINCE should be fine.

It is strange it does not work with Qt4.  Are you sure that all the include 
paths are passed to moc?
Otherwise, you will have to work around it somehow.
try #if not QT_DEPRECATED_SINCE() #else
Or some other trick with Q_MOC_RUN


You can also use the QT_MOC_COMPAT macro in front of a declaration so QObject 
will throw a runtime warning when connecting to this signal. (in debug mode)


 It seems that the new moc doesn't use much of the Qt 5 only classes, would
 it be useful to backport it to Qt 4 to avoid having to break the code
 style for modules supporting both series ?

This is out of question.
This is a behaviour change as Qt4 code relied on moc not expending the macro 
in some cases.

(At some point it will be time to switch fully to Qt5 and drop Qt4 support)


-- 
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


[Development] moc 4.8.6 macros

2014-09-11 Thread Samuel Gaist
Hi,

I've stumbled on https://bugreports.qt-project.org/browse/QTBUG-41190 which 
states that QtSerialPort cannot be built with Qt 4.8.6. 

From a quick look and build, it's the use of the QT_DEPRECATED_SINCE macro 
around the signals that makes moc miss them and thus the compilation fails.

Is there something that can be done outside of moc to workaround the problem ? 
Or does moc need to be improved ?

Thanks

Samuel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-11 Thread Thiago Macieira
On Thursday 11 September 2014 18:28:58 Samuel Gaist wrote:
 Hi,
 
 I've stumbled on https://bugreports.qt-project.org/browse/QTBUG-41190 which
 states that QtSerialPort cannot be built with Qt 4.8.6.
 From a quick look and build, it's the use of the QT_DEPRECATED_SINCE macro
 around the signals that makes moc miss them and thus the compilation
 fails.
 Is there something that can be done outside of moc to workaround the problem
 ? Or does moc need to be improved ?

NEVER #ifndef signals and slots, unless it's a simple #ifdef/#ifndef and the 
#define is present in the source file being processed.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-11 Thread Samuel Gaist

On 11 sept. 2014, at 20:50, Thiago Macieira thiago.macie...@intel.com wrote:

 On Thursday 11 September 2014 18:28:58 Samuel Gaist wrote:
 Hi,
 
 I've stumbled on https://bugreports.qt-project.org/browse/QTBUG-41190 which
 states that QtSerialPort cannot be built with Qt 4.8.6.
 From a quick look and build, it's the use of the QT_DEPRECATED_SINCE macro
 around the signals that makes moc miss them and thus the compilation
 fails.
 Is there something that can be done outside of moc to workaround the problem
 ? Or does moc need to be improved ?
 
 NEVER #ifndef signals and slots, unless it's a simple #ifdef/#ifndef and the 
 #define is present in the source file being processed.
 

The thing is, it's not even a #ifdef, it's only a #if

What would be the correct procedure to handle QT_DEPRECATED_SINCE ? Removing it 
from around the signal declaration would make the code a bit inconsistent.

By the way, how is it handled in Qt 5 since building goes without any problem 
even with the macros around the signal ?


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-11 Thread Thiago Macieira
On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote:
 What would be the correct procedure to handle QT_DEPRECATED_SINCE ? Removing
 it from around the signal declaration would make the code a bit
 inconsistent.
 
 By the way, how is it handled in Qt 5 since building goes without any
 problem even with the macros around the signal ?

moc is smarter in Qt 5: it expands macros.

But the recommendation stands: do not #if (of any kind) anything that isn't 
#defined in the same source, in a header next to the one being compiled, or 
passed as -D in the command-line.

That means: don't hide signals and slots with #if, even for deprecation.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-11 Thread Samuel Gaist

On 11 sept. 2014, at 21:49, Thiago Macieira thiago.macie...@intel.com wrote:

 On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote:
 What would be the correct procedure to handle QT_DEPRECATED_SINCE ? Removing
 it from around the signal declaration would make the code a bit
 inconsistent.
 
 By the way, how is it handled in Qt 5 since building goes without any
 problem even with the macros around the signal ?
 
 moc is smarter in Qt 5: it expands macros.
 
 But the recommendation stands: do not #if (of any kind) anything that isn't 
 #defined in the same source, in a header next to the one being compiled, or 
 passed as -D in the command-line.
 
 That means: don't hide signals and slots with #if, even for deprecation.

I thought I've read somewhere that moc got better at this job :-)

It seems that the new moc doesn't use much of the Qt 5 only classes, would it 
be useful to backport it to Qt 4 to avoid having to break the code style for 
modules supporting both series ?

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] moc 4.8.6 macros

2014-09-11 Thread Thiago Macieira
On Thursday 11 September 2014 22:03:03 Samuel Gaist wrote:
 I thought I've read somewhere that moc got better at this job :-)
 
 It seems that the new moc doesn't use much of the Qt 5 only classes, would
 it be useful to backport it to Qt 4 to avoid having to break the code
 style for modules supporting both series ?

Definitely not. Too intrusive a change. We did find breakage long after the 
change went in so we know for a fact that there's Qt 4 code that will start to 
silently fail.

No, fix qtserialport and anywhere else that a signal or a slot got #ifndef'ed 
out.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development