qmake: Can't Get DISTFILES to Work

[tbrowder]

I have a src.pro file (unix app) that works fine for the target program. Today, following the definition for DISTFILES in the qmake documents, I tried to add:

DISTFILES += ./perl_tools/read.pl

where 'read.pl' is a utility Perl script I wrote in the 'perl_tools' subdirectory.

When I run qmake and look at the Makefile I see the file listed under 'DIST'.

When I run make, the target builds and is placed in the DESTDIR location, but the Perl script doesn't show up there.

What am I doing wrong?

Thanks.

[ktk]

If I remember correctly, DISTFILES is only used when running 'make dist'.

[tbrowder]

You're correct--thanks.

This morning I've tried very hard to get qmake to do what I want (using advanced features), but have failed to do so. I'm trying to get some extra files copied to the build destination but I don't think it can be done. I have to do some more playing around with the INSTALLS variable, but my experiments so far have been disappointing.

My current solution is to have a separate Makefile (not named 'Makefile') that does the copy.

To me. one of the real drawbacks to Qt is qmake--it needs to be more extensible by the user.

For instance, a year or so ago I submitted a suggestion to Trolltech that during installation (at least in a unix environment) the fairly standard environment variables CC and CXX should be checked for the user's desired compiler, but as of 4.4 that doesn't happen (so I edit mkspecs manually). To be fair, I haven't checked all their installation variables--I'll try to remember to check when I get to work tomorrow,

And, at least in a unix environment, qmake should allow command line arguments to be passed to make.

I do use my own makespecs features (.prf) file, but it doesn't solve all needs.

An immediate fix would be to allow multiple build targets in a single pro file and define different build actions for each target. The limited documentation implies that it can be done, but I haven't had any success yet. Suggestions welcome.

Thanks for listening to my rant.

(I guess I'll have to see what qmake source looks like--yuck!)

[ktk]

http://paulf.free.fr/undocumented_qmake.html gives a few very interesting hints. But in general I agree, qmake documentation could be better, and it's
not very consistent in general ;-}

[tbrowder]

http://paulf.free.fr/undocumented_qmake.html gives a few very interesting hints. But in general I agree, qmake documentation could be better, and it's
not very consistent in general ;-}

Thanks, ktk, interesting link.

[wysota]

For qmake features you can have a look at our wiki.

As for copying files - I think you can do it by providing a separate target and stating it as a post dependency of the main target. Your dummy target should have a commands attribute with a script that performs the copy.

And, at least in a unix environment, qmake should allow command line arguments to be passed to make.

I'm not sure what do you mean here... qmake doesn't call make - you do.

An immediate fix would be to allow multiple build targets in a single pro file and define different build actions for each target.

This is possible. There's even an article on labs that describes it.

[tbrowder]

For qmake features you can have a look at our wiki.

As for copying files - I think you can do it by providing a separate target and stating it as a post dependency of the main target. Your dummy target should have a commands attribute with a script that performs the copy.

I've tried that, but no luck so far. I'll be glad to post my effort for critique.

I'm not sure what do you mean here... qmake doesn't call make - you do.

Well, since I script the calls to qmake, I would like to control arguments on a case-by-case basis, i.e., pass the arguments to qmake which would then be embedded in the generated Makefile.

This is possible. There's even an article on labs that describes it.

Thanks, I'll try to find it.

[tbrowder]

This is possible. There's even an article on labs that describes it.

I found the article. There's just one problem: the extra targets are not put with the "all" target, so the user would have to execute multiple make commands.

I can do that now with my own hand-made Makefile.

My qmake enhancement would allow the extra target to be added to the "all" target.

[wysota]

I found the article. There's just one problem: the extra targets are not put with the "all" target, so the user would have to execute multiple make commands.

Not really. You can make the new target a pre or post dependency of the original one hence it will be built with the original.

My qmake enhancement would allow the extra target to be added to the "all" target.

As far as I know qmake will be history soon (don't ask me when, I don't know, probably "soon" is "some undefined time in future"), so maybe the new mechanism will have what you require.