instead of having each generator do its own magic (little surprisingly,
with different outcomes), add "stuff" to the search path in one place
used by all generators. this has several consequences:
- (unless disabled via CONFIG+=no_include_pwd) $$PWD is now consistently
prepended by all generators. most notably, this was entirely missing
from the MSVC generators (both nmake and VS) - despite them needing it
most. this also affects Xcode projects.
- $$OUT_PWD (if different from $$PWD) is now added right after $$PWD,
not at the end. this precedence clarification only makes sense, given
that qmake tries to make shadow builds as transparent as possible.
- the qmakespec's dir is now consistently appended. the UNIX and PBX
generators prepended it, while the rest already appended. few files
actually include qplatformdefs.h, so having it late in the search path
seems reasonable.
- the effect of CONFIG+=depend_includepath is now fully consistent with
the actual include path.
Change-Id: I5f7570183351ade29342ea74fef706a0738842bf
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
neither qmake_getpwd()'s return value nor a fileFixify()'d version of it
can be empty.
Change-Id: Ic3b7d20becc57209b9dbe71ad9dc8e7547d435b1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is not used or referenced anywhere
Change-Id: I02e1aa76631627f64e5d1f9b36a13cdb5677e93f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Running 'make distclean' should remove all files generated by qmake,
including .qmake.stash/super. These files are considered owned by
a particular project (and hence a candidate for distclean), if it
lives in the same directory as the output dir of the project.
Task-number: QTBUG-42678
Change-Id: I224e9bac039eeacb6561e18acc7f8e867da5dab8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
We don't need to modify ResourceOutputFileName. The default is fine,
and $(InputName) evaluates to nothing in VS >= 2010.
Change-Id: Ib203d36261e1b5449c5a139b1950bd0d66197297
Task-number: QTBUG-43026
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
This fixes a regression introduced by
04d3a89e20 as it left out the custom build
step for the source code file generated for PCH.
Task-number: QTBUG-42596
Change-Id: I53d5a36b842dcffbde2657910e6a96dca0e99c7b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
With multi-architecture builds and ONLY_ACTIVE_ARCH set to NO, Xcode will
build the final target for multiple architectures at the same time, but
CURRENT_ARCH will only match one of them, so we failed to set up the
right dependencies for our pre-link step, causing the step to happen
after linking in some cases.
We now build an exhaustive dependency list based on QMAKE_XCODE_ARCHS,
so that ONLY_ACTIVE_ARCH=NO can be used for release builds targeted at
the App Store.
Change-Id: I6702f020a6970807adc624779f6dde09be62beb9
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Refactor the current app CFBundleIdentifier support:
handle frameworks as well. Add @BUNDLEIDENTIFIER@
placeholder to the OS X info.plist.lib templates.
This means the Qt frameworks will now get a valid
CFBundleIdentifier entry the same way as app bundles:
by extracting the identifier prefix from Xcode settings
and appending framework name.
Task-number: QTBUG-32896
Change-Id: Ica8f28332a88e37a823c46fca7a2c373157af020
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Since commmit 0127962e47 the
PBXResourcesBuildPhase is used only for ICONS, because the old
behavior of using it when target path is not given differed from
the documentation and behavior of the makefile generator by using
Contents/Resources as target directory when targeting osx.
The PBXResouceBuildPhase optimizes png, compiles xib or asset catalogs
and copies the rest.
The advantage is that it makes it easy to add resources to the bundle,
the only problem is that the target directory is always the resource
directory.
The copy operation currently used does not compile resources, which
makes adding .xib (for the Launch File required to support iphone 6)
and asset catalogs difficult.
So we restore the old 5.3 behavior for ios, and use the build
resources phase when possible on osx (target Contents/Resources).
On osx this still implies a difference between the makefile
generator and the xcode generator: only the latter compiles resources.
Change-Id: Id1853693e88fc46562b044efdea2bf5f9da2c98c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
The settings of the librarian were never written.
Creation of static libraries only worked by accident.
Adapted the code from the vcproj code path.
Task-number: QTBUG-30712
Change-Id: I69917f44305eb458647392d222db477fe5a5b7c8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Second attempt. MSVCPROJ_TARGET contains the resolved target name,
including version number and target extension.
We're splitting this value into PrimaryOutput and
PrimaryOutputExtension.
PrimaryOutputExtension is only written if it contains a non-default
value.
Task-number: QTBUG-26782
Change-Id: I4b828dc5dd47322f653585aee1a5767f0cf8bd48
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Commit 4f21eb03 utterly broke the project file generation for
VS 2008. The introduced filterByName convenience methods looks for
filter names like "Generated Files", but the code path for
VS <= 2008 used filter names like "GeneratedFiles".
The generated projects were valid but empty.
This commit ensures that both VS generators use the same filter
names.
Task-number: QTBUG-41821
Change-Id: I828fa911bae8d835b073a4c2260316127cc72cda
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Commit 4f21eb03 broke the generation of non-flat vcxprojs.
XTreeNode passes filter names to outputFileConfigs that have
the source subdirectory suffixed (e.g. "Generated Files\subdir").
That's why the original code tested the filter names with
QString::startsWith.
I've changed the signature of outputFileConfigs to take a filterId
parameter which contains the unaltered filter name (e.g.
"Generated Files") that will determine the correct filter.
Task-number: QTBUG-41746
Change-Id: If33428526a098f433cd6ceb8ab6608bd9f94ef17
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
otherwise we'll produce lines with tens of thousands columns when
dealing with QMAKE_BUNDLE_DATA.
Change-Id: Ia2a70f25e4ee1d3fe976027a7c46d234809a3f70
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
According to Apple's documentation [1], framework bundles don't
have a 'Contents' folder. Instead, each version folder gets a
'Resources' folder which contains the Info.plist file, and which
is also symlinked at the top-level framework folder.
[1]: https://developer.apple.com/library/mac/documentation/macosx/conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html
Task-number: QTBUG-32895
Change-Id: I5e55cc097b179012add0ceb7c567dace8e282895
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
the target path may have multiple components, e.g. Headers/private.
obviously, only the first component must be linked in such cases.
Task-number: QTBUG-32895
Change-Id: If632b3b72c170a9fde36e62c165e06ded53deda3
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
multiple QMAKE_BUNDLE_DATA entries can install into the same directory,
but it obviously makes no sense to symlink that repeatedly.
Change-Id: If65f7acdf4e158e33511917a027a380e642e2f28
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
instead of duplicating the plist/icon/bundled_files logic just to obtain
the dependencies, create them as a side effect of the actual target
creation.
Change-Id: I6a0fe26c82c490b1040a7a06d5d0e7a4567ae1af
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Add @FULL_VERSION@ -> Qt version substitution to
unixmake2.
This makes the Qt-generated Info.plist files compliant
with the bundle signing/validation process.
Task-number: QTBUG-32896
Change-Id: I1818f028c2f740d699629dd78cc0fe6ffaf94a1c
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
We do so by setting a 'no_plist' config property. Can be overridden
with 'force_debug_plist'.
The debug version of Info.plist would overwrite the release version,
and it also happens to contain invalid data. In particular,
CFBundleExecutable would contain the _debug suffixed libname, which
it shouldn't. See the entry about CFBundleExecutable on
https://developer.apple.com/library/ios/documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
Task-number: QTBUG-32894
Change-Id: Ideb018e4768a7c4e276e1b07d77937451f6db6a2
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
this allows us to extend its dependencies, which we will make use of later.
Change-Id: I8809bdffb435455338e88e97049b10beeab0468a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
There's a comment in VCXProjectWriter::outputFileConfigs that
states: "We need to check if the file has any custom build step.
If there is one then it has to be included with 'CustomBuild
Include'".
This patch adds the code to the comment...
Task-number: QTBUG-30373
Change-Id: Ibfef3c80630e08c743bfadce299a8b6a0c58411f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Move common code into a function
and exit early from simple search loop.
Change-Id: I88d1227653e28badc213fbe4ebe1e2a19f6e5793
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The static CRT, libcpmt.lib, is not shipped with Visual Studio Express
for Windows (unlike VS Express for Windows Desktop or Professional
versions), causing configure and qmake to fail linking if this is the
only VS installed. By removing -MT (which is on by default) and adding
$(CFLAGS_CRT) to the compiler line, -MD can be added to the compiler
flags via the environment, providing a workaround for the issue.
Change-Id: I5613346d60a3a1889c121f04d53b09fbb147fc02
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Those initializations are done by the constructors already.
Change-Id: Ife58675e2ba4854ef66c813158cb4ed660f530d1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The fileAdded variable is used to save state between iterations.
There's no need for two variables.
Change-Id: I8144cf7c7b394255459295b82a7ca808bc3951da
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We don't need the filtername parameter.
Change-Id: I653db4a200c83d095520b47e1451dfe59b956d92
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Files in "Deployment Files" should be added as static content, which
happens to be the fallback in the case where checkDeploymentFiles is
false. Also, the calling code expects that an XML tag is added in all
cases. This did not happen for the "Resource Files" filter when
checkDeploymentFiles was false, which led to unmatched closing tags.
This fixes the issue that files added to RESOURCES in different build
variants produced invalid vcxproj files.
Task-number: QTBUG-30373
Change-Id: Ibb27e67641ba63150938cf826ea1881d182fb841
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Put common code into a function.
Subsequent patches will become easier.
Change-Id: I0d549886585d90e4701a2430503bc0d2d716e341
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Make use of the mythical C++ feature "function" to soothe the brain ache
of anyone who looks into this part of the code.
Change-Id: I740e29f1777d91d3b34a61fa62a5c23c222334b9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
