A few design questions...

mzimmers

What you can do is ionstall the file besides you exe and use QCoreApplication::applicationDirPath()

True, but then the QML file is out of the source structure. I'm trying to preserve a separation between source files (of all kinds) and makefile output. It seems like good CM practice if nothing else. I guess I'm probably stuck with the relative pathnames, huh?

giesbert

Typically, you design the app so it will work on target machines with installed files, not with developer structures. Make it part of the makefile to copy the file to the out dir?

mzimmers

Now THAT'S a good idea, and will obviate the issue completely. But...makefiles are automatically generated, right? How can I do this in such a way that will survive blowing away the makefile and regenerating it?

giesbert

read the qmake docs. I'm sure there is some possibility, but I never needed that :-)

mzimmers

But...it's not really a qmake function, is it? Because this special behavior should survive the makefile. Is there a way to do this in the project file?

giesbert

but the *.pro files are described in the qmake "documentation":http://doc.qt.nokia.com/latest/qmake-manual.html

"lmgtfy":http://www.lmgtfy.com/?q=qmake+adding+copy

e.g. "this page":http://paulf.free.fr/undocumented_qmake.html

or this on "stackoverflow":http://stackoverflow.com/questions/3984104/qmake-how-to-copy-a-file-to-the-output

ZapB

You can do this by defining a custom target in your .pro file. Something like this will do it:

@
myresources.path = $$(MY_INSTALL_ROOT)/resources
myresources.files = myqmlfile.qml

INSTALLS += target myresources
@

The above depends upon the environment variable $MY_INSTALL_ROOT being set. However, this hardcodes the install path.

Instead, it is better to get rid of the $$(MY_INSTALL_ROOT) part of the path and use the DESTDIR feature of make to specify your installation root:

@make DESTDIR=/my/installation/path install@

That separates the install path from your project files.

mzimmers

Sorry if I seem a little slow on the uptake here -- I'm coping with multiple unfamiliar concepts. It's been over 20 years since I've used makefiles, and I'm still trying to figure out project files, qmake, QDir and other stuff.

Zap: I like the way your approach looks. I can't find anything on DESTDIR in the docs, though. It's not clear to me how this approach obviates the hardcoding issue; it seems to just postpone it. Obviously I'm not understanding the whole thing.

Thanks.

goetz

First: Go with the Resource directory in the application bundle. That's the expected path on OS X. One should not change those things only when it is absolutely necessary.

qmake has support for adding additional files to the bundle:

@
APP_QML_FILES.files = path/to/file1.qml path/to/file2.qml
APP_QML_FILES.path = Contents/Resources
QMAKE_BUNDLE_DATA += APP_QML_FILES
@

This installes the files to YourFancyApplication.app/Contents/Resources - just where it belongs on OS X :)

EDIT: Some more background links in the new "wiki article":http://developer.qt.nokia.com/wiki/Resource_files_in_OS_X_bundle

mzimmers

Thanks, Volker. I realize that files should be in the application bundle, and I wasn't suggesting to do it a different way. In the back of my mind, though, I'm wondering what that bundle looks like when copied to a PC. I'm hoping it's a directory.

Do I correctly assume the path/to refers to the path to the source code? Or is that the target?

EDIT:

I tried it two ways:
@APP_QML_FILES.files = ./DemodShaperFilter.qml
APP_QML_FILES.path = Contents/Resources
QMAKE_BUNDLE_DATA += APP_QML_FILES
@

and:
@APP_QML_FILES.files = DemodShaperFilter.qml
APP_QML_FILES.path = Contents/Resources
QMAKE_BUNDLE_DATA += APP_QML_FILES
@

Neither put the file into the Resources folder. It appears that the path is required, which surprises me, because I figured that the .pro file would use its own directory as the default.

So now, the question is: is there some slick way to derive the current path from an environment variable or something, and plug it into the .pro file automatically?

I'm not pursuing this level of automation out of laziness; it's more a matter of having one less thing to remember when stuff gets changed.

Thanks.

goetz

[quote author="mzimmers" date="1301602502"]Thanks, Volker. I realize that files should be in the application bundle, and I wasn't suggesting to do it a different way. In the back of my mind, though, I'm wondering what that bundle looks like when copied to a PC. I'm hoping it's a directory.

Do I correctly assume the path/to refers to the path to the source code? Or is that the target?[/quote]

Thats the path of the source. The target path (relative to the bundle) is in the second line.

If you just care about copying the Mac bundle to a windows box, then you're right, it is nothing more than an ordinary directory. On the Mac command line you just "cd" into it, like into every other directory. It's just the Finder that displays the bundle differently and if you call "open myprogram.app" on the command line, it does not open Finder (like for directories) but launches the application.

Regarding deployment on Windows, that's a different beast. You'll probably consider using an installer to put everything in place. You find some hints on windows installers in "this thread":http://developer.qt.nokia.com/forums/viewthread/4498

mzimmers

Volker: you posted about the same time I edited my last post, so I'm not sure if you saw my new comments/questions?

goetz

The path is relative to the location of your .pro file.

mzimmers

Hmm...well, then it should have worked, no?

What totally obvious thing am I overlooking? I could post the entire .pro file if that would help.

goetz

Yep, it should have worked. Is the QML file in a subdirectory?

You can try with a test file like this:

@
APP_QML_FILES.files = Makefile
APP_QML_FILES.path = Contents/Resources
QMAKE_BUNDLE_DATA += APP_QML_FILES
@

Not that a Makefile in the Resources is very useful, but it serves well for demonstration purposes :-)

For another test, you could add the absolute path to the QML to APP_QML_FILES.files.

And as a third guess, do you use shadow builds?

mzimmers

QML file is in same directory as .pro file.

Regarding adding the absolute path: I'll re-ask my question of whether there's a way to do it symbolically. Otherwise, it doesn't really solve the problem.

Shadow builds: I have a parallel directory to my source, called NNN-build-desktop. That's where all my built files go to live. Is that a shadow build, and if so, is it a bad thing, and if so, how do I do something else?

Thanks.

goetz

I don't know about a function that returns the path of the .pro file. As far as I remember this question raised in the forums some time ago.

Shadow builds are not a problem. I just checked with my test project. (EDIT: yep, the parallel directory is a shadow build)

It must be something different, probably a typo or so. You can post the .pro file here and the contents of your directory, so we can check again. If you don't want to expose your data publicly, contact me via private message to negotiate a "secure" channel.

mzimmers

No, I think it's safe to share filenames, for now at least.

Here's the .pro file:

@######################################################################

Automatically generated by qmake (2.01a) Mon Mar 28 17:09:16 2011

######################################################################

TEMPLATE = app
TARGET =
DEPENDPATH += . headers src
INCLUDEPATH += . headers

APP_QML_FILES.files = DemodShaperFilter.qml
APP_QML_FILES.path = Contents/Resources
QMAKE_BUNDLE_DATA += APP_QML_FILES

QT += declarative

Input

HEADERS +=
headers/clock.h
headers/DemodShaperFilter.h
headers/globals.h
headers/register_offsets.h
headers/Soc.h
headers/SocReg.h
headers/widget.h
headers/GenericCell.h
SOURCES +=
src/clock.cpp
src/DemodShaperFilter.cpp
src/filestuff.cpp
src/globals.cpp
src/main.cpp
src/Soc.cpp
src/SocReg.cpp
src/widget.cpp
src/GenericCell.cpp

FORMS +=
widget.ui

OTHER_FILES +=
DemodShaperFilter.qml
@

And here's a snapshot of my directory:

!http://www.scopedin.com/images/screen.jpg(directory)!

Thanks...

mzimmers

I found the problem: Contents/Resources isn't where the executable is; it's in Contents/MacOS. Works fine now.

That was a nice diversion; now I'll get back to trying to do what Zap mentioned several posts ago. I'll be back with questions about that soon.

mzimmers

So, Zap: from reading the section on Q_PROPERTY, it appears that within my top-level class, I replace the variable creation with a Q_PROPERTY. So, instead of:

@int combGainI;@

I'll now have something like:

@ Q_PROPERTY (int combGainI READ readFn WRITE writeFn);
@

Correct so far?

So, since I have to supply a read and write function, am I correct in assuming that this can no longer be an int? I have to make a class for the combGain, and provide gets and sets for it?

Thanks.