Oswald Buddenhagen wrote:
> yes. except that i want these to be called QMAKE_BUNDLE_*.
> this is irrespective of x-platform use. i like the idea of calling the
> functionality "bundling".
Yup, that sounds better. So they will be:
QMAKE_BUNDLE_LIBRARIES
QMAKE_BUNDLE_PLUGINS
QMAKE_BUNDLED_LIBRARIES_DIR
QMAKE_BUNDLED_PLUGINS_DIR
Example:
mac {
weirdlib.src = /Library/Frameworks/WeirdLib.framework
weirdlib.dst = $$join($$QMAKE_BUNDLED_LIBRARIES_DIR,
SubFolderForSomeReason)
weirdlib.headers = true
weirdlib.variants = debug release
QMAKE_BUNDLE_LIBRARIES *= \
weird lib \
/Library/Frameworks/Sparkle.framework \
/usr/local/lib/liblua.dylib
} else {
weirdlib.src = /usr/local/weirdlib.so
weirdlib.variants = debug release
QMAKE_BUNDLE_LIBRARIES *= \
weirdlib \
/usr/local/lib/liblua.dylib
}
@Jake: I don't think we need separate vars for frameworks and plain libraries.
If their need slight different handling, we can figure out that checking
extension.
> i'm not so sure about the details.
> the thing is that the .dst specification is way too "precise", thus
> making x-platform use impossible. even the existing QMAKE_BUNDLE_FILES
> isn't that precise (which enables supporting ios and osx bundles without
> changes to the project ... provided somebody bothers to polish up the
> qmake changes that are supposed to make this actually work).
If we drop OS X specific naming, then I don't see what isn't x-platform. Maybe
weirdlib.headers is kind of OS X specific, but otherwise. Of course is someone
needs to bundle some specific libraries, probably it needs platform dependent
conditionals, because source location will be likely different.
> i'm kind of losing at least one of you guys here.
> it's beyond obvious that existing projects *will* need at least one
> modification: CONFIG += bundle_qt (and possibly additional
> QMAKE_BUNDLE_* for non-qt dependencies).
>From my perspective CONFIG += bundle_qt was more about doing bundling on
>build. But when this is left out, doing bundling on "make bundle" which will
>be equivalent of "macdeployqt".
> there is no way i'd allow
> a major behavior change like making this the default.
Completely makes sense to me. But if I understand correctly, you mean existing
projects may expect macdeployqt? Or I am missing something else.
> and when these options are enabled, it seems pretty much a no-brainer
> that qmake would also automatically add the right rpaths to make these
> bundled dependencies actually useful. why would you ever *not* do that?
Yes, I believe we all agree on that now.
--Adam
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
