[Interest] problem with type registration during QML module compilation

[Stefan Seefeld]

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 scales.

Regards,

On Sat, Jul 13, 2024 at 1:17 AM Mike Trahearn <
miketrahearn at imagineuisoftware.com> wrote:

> 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 module but the original library can be elsewhere with its own include
> paths and structure, so long as the QML module library can link to it and
> reach the library's headers. The QML module need not provide any further
> implementation so long as the foreign types it is registering are well
> behaved from a QML point of view (good properties with NOTIFY/CONSTANT and
> FINAL)
> As I said, it's convoluted but it does have the advantage of being able to
> leave old code alone. That's one of the main purposes of QML_FOREIGN.
>
> On Sat, 13 July 2024, 4:38 am Stefan Seefeld, <stefan at seefeld.name> wrote:
>
>> 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 <A.h>` instead of `#include <view/A.h>` ?
>>
>> On Fri, Jul 5, 2024 at 10:15 AM Stefan Seefeld <stefan at seefeld.name>
>> wrote:
>>
>>> 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 <A.h>
>>>
>>> My library layout looks like this:
>>>
>>> libs/foo/
>>> ├── CMakeLists.txt
>>> ├── view
>>> │   ├── A.h
>>> │   ...
>>> ├── qml
>>> ...
>>>
>>> and the makefile above compiles a shared library libfoo.so from the
>>> contents. I now want to use `qt_add_qml_module()` to automate the
>>> generation of the associated QML module (including all the QML resources,
>>> as well as exposing the QML types defined in C++, such as the one in
>>> `view/A.h`. However, the generated code expects to be able to include
>>> "A.h", while it should actually be including "view/A.h". Is there a
>>> property I should be passing to `qt_add_qml_module()` to make that happen,
>>> or is there anything else I'm missing ?
>>>
>>> For context: The type `A` is actually a singleton (a QQmlPropertyMap)
>>> which is accessed directly from C++ code, so its C++ API needs to be
>>> accessible as a regular class in the library, in addition to being
>>> registered to the QML runtime.
>>>
>>> Thanks for any help,
>>>
>>> --
>>>
>>>       ...ich hab' noch einen Koffer in Berlin...
>>>
>>>
>>
>> --
>>
>>       ...ich hab' noch einen Koffer in Berlin...
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>>
>

-- 

      ...ich hab' noch einen Koffer in Berlin...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20240715/36c8a6f2/attachment.htm>