Re: [Interest] Three-file modules vs. moc
> If you turn automoc on, it tries to guess which moc files need to be > generated > and which ones are #included by way of regular expressions too. If you don't > like that, don't use automoc. Ok, I see, thanks. If cmake/automoc uses the same basic search and if there is no interest/plans in making it smarter, I will drop the original idea. Currently I would like to prefer to drop moc ;) -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
On Tuesday, 1 September 2020 14:17:50 PDT Bernhard Lindner wrote: > Anyway, how does cmake behave regarding the described moc target detection > problem? Does it work smarter than qmake? If you turn automoc on, it tries to guess which moc files need to be generated and which ones are #included by way of regular expressions too. If you don't like that, don't use automoc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Hi Thiago! > > Well, what about coming cmake in Qt6? I assume Qt Creator will support cmake > > based projects for application developers. Do you see a chance to fix the > > problem using the new tool set? > > Qt Creator has supported CMake for 10 years or more. Building Qt applications > with CMake has been officially supported since 5.0. LOL! Well, sorry, shame on me, I never had a reason to look for anything different than qmake (for Qt development). Anyway, how does cmake behave regarding the described moc target detection problem? Does it work smarter than qmake? -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
On Tuesday, 1 September 2020 12:29:29 PDT Bernhard Lindner wrote: > Well, what about coming cmake in Qt6? I assume Qt Creator will support cmake > based projects for application developers. Do you see a chance to fix the > problem using the new tool set? Qt Creator has supported CMake for 10 years or more. Building Qt applications with CMake has been officially supported since 5.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Hi Thiago! > Correct, qmake does not preprocess, but it does try to guess what your > dependencies are. This is not restricted to moc outputs: any #include found > that match a source file is automatically removed from the list of targets to > build too. Oh my! :-( > A more correct way to do this would be to use GCC's makefile dependencies > output flags (-MM, etc.). But I guess no one wants to implement new features > for qmake. You are probably right :-( Well, what about coming cmake in Qt6? I assume Qt Creator will support cmake based projects for application developers. Do you see a chance to fix the problem using the new tool set? -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
On Monday, 31 August 2020 09:31:17 PDT Bernhard Lindner wrote: > It appears to me that qmake is looking for "#include "moc_module.cpp"" using > some simple regular expression which does not take any conditional > compilation into account. Is this correct? Correct, qmake does not preprocess, but it does try to guess what your dependencies are. This is not restricted to moc outputs: any #include found that match a source file is automatically removed from the list of targets to build too. A more correct way to do this would be to use GCC's makefile dependencies output flags (-MM, etc.). But I guess no one wants to implement new features for qmake. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Hi!
> Add to your module.cpp:
>
> #include "moc_module.cpp"
>
> This is recommended anyway, regardless of your problem. Always #include the
> module output for your headers in your corresponding .cpp files.
I tried a variant of the above using C++17 __has_include:
#if __has_include("moc_module.cpp")
#include "moc_module.cpp"
#endif
My goal was easier module maintenance by automatic inclusion of moc-code in
case moc found
relevant code in the header. Especially after reworking a module this can be
easily
forgotten without the above.
Then I get this error:
No rule to make target 'moc_module.cpp', needed by 'core_module.o'. Stop.
I also tried this:
#if 0
#include "moc_module.cpp"
#endif
Same error.
It appears to me that qmake is looking for "#include "moc_module.cpp"" using
some simple
regular expression which does not take any conditional compilation into
account. Is this
correct?
--
Best Regards,
Bernhard Lindner
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Il 27/08/20 20:46, Bernhard Lindner ha scritto: This is recommended anyway, regardless of your problem. Always #include the module output for your headers in your corresponding .cpp files. Can you explain that general recommendation? It seems to me that such includes are only useful in special cases like mine and like .cpp files containing moc relevant code. Including moc from the C++ code reduces compilation times (one "slightly larger" file to compile, not two) and enables the compiler to optimize more aggressively without resorting to LTO. As such it's always useful to do. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Hi Thiago! > Add to your module.cpp: > > #include "moc_module.cpp" Works well, thank you! > This is recommended anyway, regardless of your problem. Always #include the > module output for your headers in your corresponding .cpp files. Can you explain that general recommendation? It seems to me that such includes are only useful in special cases like mine and like .cpp files containing moc relevant code. -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
On Wednesday, 26 August 2020 12:40:31 PDT Bernhard Lindner wrote: > Hi! > > Currently I am facing a problem with a Qt Creator managed Qt 5 project. > > The projects consists of a lot of modules and implements a special but > useful file concept. Each module has 3 files: >module.hpp - Public types, macros and declarations >module.inl - Template function definitions, constexpr and inline function > definitions module.cpp - All other definitions > module.cpp includes module.inl and module.inl includes module.hpp. > How can I solve this problem on the moc side? Is there a way to tell moc via > the .pro project on a per-module basis to include module.inl instead of (or > along with) module.inl in moc_module.cpp? Add to your module.cpp: #include "moc_module.cpp" This is recommended anyway, regardless of your problem. Always #include the module output for your headers in your corresponding .cpp files. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Hi! > I wonder how clients of the class declared in the .hpp file can use that > class at all. > Unless I am missing something, they won’t be able to (at least not in the > general case) > unless they also include the .inl file. Depends from what part of the module API you want to use. E.g. if only macros or types/classes are need, including the .hpp is faster and sufficient. This means a .hpp will typically include other .hpp. If you want to call functions you will include .inl. This means a .cpp or a .inl will typically include other .inl. > Wouldn’t it be simplier to #include the inl file in the hpp file? That way > you still > have separation of declaration and definition on a file-level, but don’t > expose users of > your C++ headers (including moc) to your way of organizing things. Tried that before. Then it turned out that on the .inl level a mutual dependency lock can happen (similar to what you get if normal hpp/cpp modules try to include include eachother without using forward declarations). Only the two-level-inclusion as described above reliably solves all mutual inclusion issues. -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
On Thu, Aug 27, 2020 at 5:43 AM Bernhard Lindner < priv...@bernhard-lindner.de> wrote: > > You might also use a custom extra compiler -- that still invokes moc, > > but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl, > > and so on... > > Hm, I see. Has something like that been done before, is there code I could > reuse? > This is for a rather different use case but attached to https://bugreports.qt.io/browse/QTBUG-81348 you can find two (very similar) examples of how to write a custom feature that runs moc in a different way than the default. Adam ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Hi Bernhard, I use plain .pro and .pri files with qmake to Visual Studio projects. Moc has a feature that prevents the output files being treated as separate compiles - if it finds the include in the relevant module .cpp. It works really well for us with thousands of modules. I not sure how that work flow translates to Qt Creator. If you add #include as the second line in spinbox.cpp, and then run qmake or whatever the Creator equivalent is. After that, the moc steps will run as normal, and then the compile of spinbox.cpp without a separate compile for moc_spinbox.cpp. Hope that helps, Tony On 27/08/2020 5:40 am, Bernhard Lindner wrote: Hi! Currently I am facing a problem with a Qt Creator managed Qt 5 project. The projects consists of a lot of modules and implements a special but useful file concept. Each module has 3 files: module.hpp - Public types, macros and declarations module.inl - Template function definitions, constexpr and inline function definitions module.cpp - All other definitions module.cpp includes module.inl and module.inl includes module.hpp. I added all .hpp file names to the .pro file using Qt Creator. All moc relevant .hpp files are parsed fine by moc and a moc_module.cpp file is generated for each module as usual. Unfortunately the moc_module.cpp files includes module.hpp only, since module.inl are unknown to moc. So all function definitions from moc_module.inl are unknown during compilation of moc_module.cpp and I get undefined reference linker errors (e.g. for property related setters called in the moc_module.cpp code). Maybe I could use a lot of Q_MOC_RUN preprocessor conditions to work around but that would pollute the code awfully. How can I solve this problem on the moc side? Is there a way to tell moc via the .pro project on a per-module basis to include module.inl instead of (or along with) module.inl in moc_module.cpp? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
> On 27 Aug 2020, at 14:42, Bernhard Lindner > wrote: > > Hi! > >> Can you make an example of your structure (what's exactly in each of the >> three files)? It's not entirely clear. > > Ok, I attached an example of a module containing some pseudo code. Please > tell me if you > need more information. > >> You might also use a custom extra compiler -- that still invokes moc, >> but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl, >> and so on... > > Hm, I see. Has something like that been done before, is there code I could > reuse? I wonder how clients of the class declared in the .hpp file can use that class at all. Unless I am missing something, they won’t be able to (at least not in the general case) unless they also include the .inl file. Wouldn’t it be simplier to #include the inl file in the hpp file? That way you still have separation of declaration and definition on a file-level, but don’t expose users of your C++ headers (including moc) to your way of organizing things. Volker ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Hi!
> Can you make an example of your structure (what's exactly in each of the
> three files)? It's not entirely clear.
Ok, I attached an example of a module containing some pseudo code. Please tell
me if you
need more information.
> You might also use a custom extra compiler -- that still invokes moc,
> but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl,
> and so on...
Hm, I see. Has something like that been done before, is there code I could
reuse?
--
Best Regards,
Bernhard Lindner
#include "spinbox.inl"
SpinBoxU64::SpinBoxU64(QWidget* pParent) noexcept :
AbstractSpinBox(pParent)
{
}
#ifndef SPINBOX_HPP
#define SPINBOX_HPP
template
class AbstractSpinBox : public QAbstractSpinBox
{
public:
explicit AbstractSpinBox(QWidget* pParent = nullptr) noexcept;
T value() const noexcept;
void setValue(const T& pValue) noexcept;
T minimum() const noexcept;
void setMinimum(const T& pMinimum) noexcept;
T maximum() const noexcept;
void setMaximum(const T& pMaximum) noexcept;
...
};
class SpinBoxU64 : public AbstractSpinBox
{
Q_OBJECT
Q_PROPERTY(quint64 minimum READ minimum WRITE setMinimum)
Q_PROPERTY(quint64 maximum READ maximum WRITE setMaximum)
Q_PROPERTY(quint64 value READ value WRITE setValue NOTIFY valueChanged USER true)
public:
explicit SpinBoxU64(QWidget* pParent = nullptr) noexcept;
signals:
void valueChanged(const quint64& pValue);
...
};
#endif // SPINBOX_HPP
#ifndef SPINBOX_INL
#define SPINBOX_INL
#include "spinbox.hpp"
template
AbstractSpinBox::AbstractSpinBox(QWidget* pParent) noexcept :
QAbstractSpinBox(pParent)
{
}
template
void AbstractSpinBox::setMinimum(const T& pMinimum) noexcept
{
}
template
void AbstractSpinBox::setMaximum(const T& pMaximum) noexcept
{
}
template
void AbstractSpinBox::setValue(const T& pValue) noexcept
{
}
template
inline T AbstractSpinBox::minimum() const noexcept
{
}
template
inline T AbstractSpinBox::maximum() const noexcept
{
}
template
inline T AbstractSpinBox::value() const noexcept
{
}
#endif // SPINBOX_INL
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Hi, Can you make an example of your structure (what's exactly in each of the three files)? It's not entirely clear. Il 27/08/20 13:26, Bernhard Lindner ha scritto: Hm. I am not sure I get it. That is a global option, right? I have a LOT of modules, each with a different name. When adding an -f option for each of them, each moc_*.cpp file would include all *.inl includes... which would increase compile time exponentially. I would like to avoid that. You might also use a custom extra compiler -- that still invokes moc, but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl, and so on... -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
Hi! > > I added all .hpp file names to the .pro file using Qt Creator. All moc > > relevant > > .hpp files are parsed fine by moc and a moc_module.cpp file is generated for > > each module as usual. > > Have you tried adding the .inl files to HEADERS instead? Yes. But it didn't work. Even more undefined references. module.inl never contains moc relevant code but module.hpp does. I guess for this to work, moc would need to resolve the contained #include "module.hpp". It generally doesn't resolve includes, does it? > > Unfortunately the moc_module.cpp files includes module.hpp only, since > > module.inl are unknown to moc. > > So all function definitions from moc_module.inl are unknown during > > compilation of moc_module.cpp and I get undefined reference linker errors > > (e.g. for property related setters called in the moc_module.cpp code). > > You can let moc add additional includes in it's output via -f argument, > Custom options to moc can be set in qmake via QMAKE_MOC_OPTIONS. Hm. I am not sure I get it. That is a global option, right? I have a LOT of modules, each with a different name. When adding an -f option for each of them, each moc_*.cpp file would include all *.inl includes... which would increase compile time exponentially. I would like to avoid that. -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Three-file modules vs. moc
> -Ursprüngliche Nachricht- > Von: Interest Im Auftrag von Bernhard > Lindner > Gesendet: Mittwoch, 26. August 2020 21:41 > An: interest@qt-project.org > Betreff: [Interest] Three-file modules vs. moc > > Hi! > > Currently I am facing a problem with a Qt Creator managed Qt 5 project. > > The projects consists of a lot of modules and implements a special but useful > file concept. Each module has 3 files: >module.hpp - Public types, macros and declarations >module.inl - Template function definitions, constexpr and inline function > definitions >module.cpp - All other definitions > module.cpp includes module.inl and module.inl includes module.hpp. > > I added all .hpp file names to the .pro file using Qt Creator. All moc > relevant > .hpp files are parsed fine by moc and a moc_module.cpp file is generated for > each module as usual. Have you tried adding the .inl files to HEADERS instead? > Unfortunately the moc_module.cpp files includes module.hpp only, since > module.inl are unknown to moc. > So all function definitions from moc_module.inl are unknown during > compilation of moc_module.cpp and I get undefined reference linker errors > (e.g. for property related setters called in the moc_module.cpp code). You can let moc add additional includes in it's output via -f argument, Custom options to moc can be set in qmake via QMAKE_MOC_OPTIONS. > Maybe I could use a lot of Q_MOC_RUN preprocessor conditions to work > around but that would pollute the code awfully. > > How can I solve this problem on the moc side? Is there a way to tell moc via > the .pro project on a per-module basis to include module.inl instead of (or > along with) module.inl in moc_module.cpp? See above. Either let moc directly parse module.inl, instead of module.hpp. Or let the generated moc file include module.inl by setting e.g. QMAKE_MOC_OPTIONS=-fmodule.inl Regards Kai ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Three-file modules vs. moc
Hi! Currently I am facing a problem with a Qt Creator managed Qt 5 project. The projects consists of a lot of modules and implements a special but useful file concept. Each module has 3 files: module.hpp - Public types, macros and declarations module.inl - Template function definitions, constexpr and inline function definitions module.cpp - All other definitions module.cpp includes module.inl and module.inl includes module.hpp. I added all .hpp file names to the .pro file using Qt Creator. All moc relevant .hpp files are parsed fine by moc and a moc_module.cpp file is generated for each module as usual. Unfortunately the moc_module.cpp files includes module.hpp only, since module.inl are unknown to moc. So all function definitions from moc_module.inl are unknown during compilation of moc_module.cpp and I get undefined reference linker errors (e.g. for property related setters called in the moc_module.cpp code). Maybe I could use a lot of Q_MOC_RUN preprocessor conditions to work around but that would pollute the code awfully. How can I solve this problem on the moc side? Is there a way to tell moc via the .pro project on a per-module basis to include module.inl instead of (or along with) module.inl in moc_module.cpp? -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
