| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Non-framework builds would automatically link to whatever Qt library
matched the config at the time of running qmake, eg hard-coded to
libQtCore_debug, while Xcode itself allowed the user to switch between
release and debug configurations.
We now append an Xcode settings variable to the library path, which gets
resolved at build time depending on the current config in Xcode.
Change-Id: I12873e38a28d9595ef3fd0ae0ad849e6744833a9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
|
| |
|
|
|
|
|
|
|
| |
... instead of as a fallback in default_post.
it was this way in qt4, and it requires less code to be written in the
end. we are already doing it for debug/release as well.
Change-Id: I6e02849d61d14a18375cf64a5990768931ebac48
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
|
|
the current approach of having "free-flying" prf files for such a core
issue is rather insane. this was noticed early on, as evidenced by the
forcible loading of debug/release/debug_and_release in default_post.
however, things remained a mess, in particular static vs. shared.
consequently, the commit merges all related feature files. the actual
config resolution is put in a separate feature file, so it can be loaded
by resolve_target if that happens to be loaded early on.
Change-Id: Ie30e7c63cabe9409a3263ca1650e323a870926f2
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
