[Development] Adding QML to qmake variables

[Tomasz Siekierda]

Hi, thanks for your reply.

On 6 December 2011 01:24,  <sarah.j.smith at nokia.com> wrote:
> Hi
>
> Comments in line below.
...
>
> You do want to be able to see these guys in the Qt Creator project browser.
>  I wonder if they are also not available via <ctrl>-K file find or project
> search, as well if they are not somehow included.
>
> Trouble with DEPLOYMENTFOLDERS is that it is really a Symbian creature, and
> thus not a good choice for this.  Especially since it might be scoped out
> easily.

I did suspect that, yes. The nice feature of this var is that it is
able to add all files in a directory recursively, which would help a
lot in my case (currently over 40 QML files, and still rising... not
that nice to have to manage them by keeping exact entries for all
files in .pro).

>
> What we in Qt3D are moving over to now is create a QML_FILES variable and
> add that to OTHER_FILES.
>
> We also put QML_FILES into a QMAKE_EXTRA_COMPILERS rule which has the
> "compiler" as just a copy command.  That is for the case where we're hacking
> on the code, and for the case where a package is being built it gets added
> to the INSTALLS instead.
>
> https://qt.gitorious.org/qt/quick3d/blobs/master/src/imports/shapes/shapes.pro#line47
>
> This works reasonably well, but again its a bit of a hack, and fragile with
> the scopes, and it would be nicer if the plumbing was hidden away a bit
> more.

Maybe, for a start, this behaviour could be incorporated in qmake
itself, before a more proper solution is found? It's hard for me to
say, I really know nothing about qmake's internal work. Would be good
if Marius responded, then.

Another crazy idea that stalks my mind, is that there could be another
qmake var, or subroutine that would automatically make QRC out of
specified files. Background: in my app, some QML (and JS) files are
"internal" and are closely related to development itself, while others
are more "public" and should be easily available to users (with the
possibility of modifying them without recompilation of the project).
This can be done with QRC nicely right now, though, so I won't treat
that idea very seriously (if someone's interested in seeing that too,
please +1 to let me/ us know).

> btw, don't look too closely at our pro scripts - they are awfully crufty
> with Symbian/Harmattan and Qt 4 legacy stuff in there which is slowly being
> refactored.  :-)

Yeah, I was about to make a nasty remark about that :-P

> Sierdzio, I think it would be a great idea to provide explicit support for
> this,

I am participating in a few projects right now, but still have time to
spare, and would be glad to help - but as I've said, I need some help
to begin the work.

>  and to do so with a view to how it appears in Qt Creator, as well as
> how it interacts with qmake - remembering that the two have different qmake
> file interpreters.

Well, another new thing for me. Good to know.

> Sadly, I have no experience in QMake development, so I won't be able
> to help in implementation much, at least not without some initial
> guidance (where to start).
>
>
> I might be wrong but I think Marius is the owner of the qmake build stuff
> right now.  Obviously for the qtcreator stuff that is a different team -
> maybe Roberto would know?

Should I ping the qtcreator mailing list, too?

> Our team don't have any bandwidth to help with implementation but I would
> love to see this happen and could maybe help with some guidance and testing.
>  :-)

Testing's always appreciated.

s.