On 7/15/24 22:14, Stefan Seefeld wrote:
Thanks Mike for the followup ! Yes, it's a shame that these tools are so
restrictive in how users may lay out their code. I'll see what the best
options are to proceed. For now I'm simply adding a private include path
to make the compiler find the header
Thanks Mike for the followup ! Yes, it's a shame that these tools are so
restrictive in how users may lay out their code. I'll see what the best
options are to proceed. For now I'm simply adding a private include path to
make the compiler find the header under the new path. We'll see whether
that s
One option I just thought of (although convoluted) is keeping your original
library as-is and then making a QML module containing not much more than
headers with structs that declare QML_FOREIGN over just the types that need
to be used in QML. Those headers can be in the same folder as the QML
modu
Hello Stefan,
I was certain I could help you so I recreated your scenario - and found the
same problem.
I tried many different ways of coaxing the include path to be visible to the
type registration system - all in vain.
So I started digging around in code reviews, docs, forums and the like. Tu
Hello,
any idea why I'm getting the below error ? What tool is used to generate
the *_qmltyperegistrations.cpp file, and how does it figure out to add the
line `#include ` instead of `#include ` ?
On Fri, Jul 5, 2024 at 10:15 AM Stefan Seefeld wrote:
> Hello,
>
> following up on an earlier conv
Hello,
following up on an earlier conversation...
I'm trying to convert a legacy QML module to use the "new"
`qt_add_qml_module` function. This process includes the generation of a
..._qmltyperegistrations.cpp file that contains an invalid reference to a
header file
My library layout looks like
