Recent versions of qmake complain loudly when the locale
does not explicitly specify the utf8 codeset. Specifically,
the configure script exports LC_ALL=C and that implies the
ascii codeset. Previously, this was silently changed to utf8,
whereas now we get a warning for each qmake invocation.
So, explicitly set utf8 before calling qmake.
The gui-private is a separate module. Private Qt6 GUI headers
are currently used only with the Windows backend. However they
are needed to port to Qt6 all functionality that was depending
on the -extras modules. For example, all code guarded by the
macro HAVE_QT5_X11_EXTRAS has to be audited and properly replaced
by Qt6 code. See for example 771f30e9 and 17b24cf4.
This is less powerful than stdlib-debug, but at least it does not
change the ABI. This avoids crashes with Qt6 in particular.
The new defaults are:
- stdlib-assertions is enabled by default in development builds;
- stdlib-debug has to be enabled explicitely.
Fixes bug #12215.
When generating makefiles, by default qmake tries to use
relative paths if it can replace at most 4 subdirs with "../"
to reach the QTDIR from the project file location.
This maximum can be changed by defining QMAKE_PROJECT_DEPTH, and
setting it to zero forces qmake to always use absolute paths.
This is necessary because the paths for includes and libs are
generated by a temporary project file located in a temporary dir
not corresponding to the real source dir.
This fixes two issues with autoconf 2.71
* a new version of eilseq.m4 from libiconv is required ;
* the AC_CHECK_HEADER last `-' argument is obsloleted, but I do not
think that we needed it in the first place.
The QWinMime class has been removed in Qt6 but the functionality
is still present. However, one has to allow inclusion of private
headers and register the mime handling to the QWindowsApplication
native interface.
We would miss the libraries specified by a full path when
also '-L' flags are present, as we would only take into
account those specified by '-l' flags.
In Qt6 the Svg includes are split into two different subdirs,
namely QtSvg and QtSvgWidgets. So, after 0862042b, it is necessary
to also account for the last one. Nothing needs to be done for Qt5.
(shamelessly stolen from c26db650a1, which was for cmake build)
The original test was always successfull, even if the flag was invalid.
But checking for '-Wdeprecated-copy' instead yields to error if the
warning does not exist. Existent warning for 'deprecated-copy' implies
that 'no-deprecated-copy' also exist.
Since Qt 6.1 the moc, rcc, and uic compilers are not installed
in the bin dir anymore. We ask qmake for their location and
record them with full path so that it is not necessary thinkering
with the PATH variable.
There is still no clear pattern of how distributions will install Qt6.
The old scheme of adding a -qtN suffix is not followed by OpenSuse,
and qmake and the ancillary programs are installed with 6 as a suffix.
This commit allows compiling LyX with Qt6 when using autotools.
For a successful compilation the following 2 conditions must be met.
1) The Qt6 qmake has to come first in PATH, so that the command
"qmake -v | grep -o 'Qt version .'" returns "Qt version 6".
2) The --enable-qt6 switch has to be passed to the configure command.
If --enable-qt6 is used but Qt6 is not found, Qt5 is tried as a fallback.
If also Qt5 is not found, configuring for Qt4 is attempted.
If --enable-qt6 is not used, then things go as usual. This means that Qt5
is tried first and then Qt4, unless --disable-qt5 is used, in which case
Qt4 is directly attempted. This means that existing scripts should
continue working unmodified.
LyX should compile with Qt6 on windows and linux, and possibly also on
mac, but I could not test that. However, it is not guaranteed that it
works as it should. In particular I am not sure that I got right the
conversion from QRegExp to QRegularExpression. For sure, the syntax
highlighting seems to not work right. Someone in the know should take
a look at that. I am able to load documents and compile them but some
thourough testing is needed. However, when compiling for Qt5 or Qt4,
I tried to make sure that the functionality is preserved.
1/ remove boost regex code from 3rdparty/boost. Only the cmake stuff remains.
2/ remove traces of BOOST_LIB since there is no need anymore to
compile boost stuff.
3/ remove traces of boost regexp in config/lyxinclude.m4 and INSTALL
4/ require gcc 4.9 as minimal version in autoconf.
Unfortunately, the net gain is only 10% of included boost size (now 21M).
Introduce new configure option --enable-cxx-mode=MODE, which allows to
force a C++ version. The default is {14,11}, which means that C++14 is
chosen if it is supported, and C++11 will be selected as a fallback.
Using --enable-cxx-mode=11 ensures that LyX compiles correctly
with an older C++11 compiler.
This is better than depending on compiler version. In particular,
Apple clang versions do not match regular clang versions.
Note that -Wno-deprecated-copy will always be used with g++, since
this compiler allows to suppress warnings it does not know about
(-Wno-zorg is valid, even though -Wzorg triggers an error).
This was already done for gcc9 and saves tons of warnings.
Note that the warning in Qt are gone with Qt5.13, so eventually we
will have to get rid of our own copy issues.
