You can place the export macros in the namespace declarations on ELF
systems and that will apply to all declarations inside that scope. If a
namespace is exported like that, then we should mark it for versioning
too.
Note that the exporting doesn't happen for declarations in other scopes
of the same namespace, even though the findclasslist.pl script will mark
everything in that namespace. This should not be a problem.
Task-number: QTBUG-55897
Change-Id: I371f5b01e24a4d56b304fffd147274778b980ad2
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Not that we require it, but since The Qt Company did it for all files
they have copyright, even if they haven't touched the file in years
(especially not in 2016), I'm doing the same.
Change-Id: I7a9e11d7b64a4cc78e24ffff142b4c9d53039846
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
It only needs stdin now, instead of stdin plus a separate file containing
a list of file names.
Change-Id: I9f3db030001e47e4a4e5ffff1425b76884cc7ca0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Recent versions of Qt have apparently added sufficient numbers of
headers that the command lines used to spawn a custom header-
parsing tool, started overflowing Windows' maximum command-line
length.
This change restructures the mechanism to use a GCC-style command-
line arguments file rather than passing filenames all directly
in the argv[] vector.
Although QNX is the usual ELF target whose cross-build is supported
on Windows, the mechanics introduced in this patch happen to affect
all other ELF Unix systems' builds too.
Change-Id: I5a7383cf9f2ebf9dffde8dbfdcdeca888265e085
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This way, it's possible to tell which applications and libraries depend
on the Qt private API and of which Qt library. Linux distributions can
use this information to decide which applications need to be recompiled
every time Qt itself is rebuilt.
This is done by scanning all class and struct definitions in the private
headers (we've already got the list from syncqt). I opted to add a new
script instead of modifying syncqt because then this can run in parallel
with the rest of the compilation, as opposed to during qmake
time. Another advantage is that it catches modifications to the headers
in between qmake executions.
Since this is already Unix specific, it should be no problem to use Perl.
This solution is limited to use of non-inline symbols of classes
declared in private headers. It will not catch free variables (such as
qsimd_p.h's qt_cpu_features), use of inlined functions or just plain use
of a class/struct for accessing its data members. However, this is
already better than nothing and should help Linux distributions quite a
lot. And there's no way to catch the latter issue anyway.
Change-Id: I049a653beeb5454c9539ffff13e3fff36400ebbd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
