[Development] [5.7-beta] qtgamepad compile failure

[Thiago Macieira]

On quinta-feira, 5 de maio de 2016 13:39:59 PDT Tim Blechmann wrote:
> compiling the qt-5.7-beta tarball with msvc2013/64bit/static libraries,
> out-of-tree build gives me:
> 
> ---
[cut]
> h:\qt3rd\qtgamepad\src\gamepad\qgamepadmanager.h(42) : fatal error
> C1083: Cannot open include file: 'QtGamepad/qtgamepadglobal.h': No such
> file or directory
> qgamepad.cpp
> 
> ---
> 
> i know ci builds with dozens of configurations are impractical and
> require a significant amount of buildserver resources. but it would be
> great if tarballs could be tested with non-standard configurations ...
> namespaced qt, static libs, out-of-tree builds, slightly older compilers
> ... all these configurations are often broken in released tarballs. i
> suppose both qt devs and users would save quite some time and
> frustrations, if these configurations could be tested as part of the
> process of releasing a tarball.

Hello Tim

It should have been. That's why we have a release team that does sanity 
checking on the packages and releasing isn't just "make a git tag and create 
packages". Though it's also true that a beta release receives less attention 
than a full one.

One thing, however, struck me in your description: you said you're building a 
*tarball* with MSVC2013. Does it mean you downloaded the .tar.gz or .tar.xz 
file for Windows? If so, be careful with line endings.

I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and 
confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present. Given 
the paths your build shows, I'm guessing you unpacked the sources in H:/qt3rd, 
which means this file should have ended up in 
	H:/qt3rd/qtgamepad/include/QtGamepad/qtgamepadglobal.h

Is that correct?

Your command line had:
	-IH:/qt3rd/qtgamepad/include -IH:/qt3rd/qtgamepad/include/QtGamepad
	-I..\..\include -I..\..\include\QtGamepad

So I have to ask: how did it *not* find the file? If your output is correct, it 
should have found by concatenating that first -I with the path being sought, 
which tells me that the difference may be a non-visible character, like a 
line-ending.

Can you confirm that the command-line you pasted refers to the file that failed 
to build? There's a "jom" command in the middle of the output, which means 
that you used jom and that it was doing parallel builds, so it's possible that 
it referred to something else. As a rule of thumb, if a parallel build fails, 
rerun with -j1 to get the actual first error with no reordering.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center