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.
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.
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.
* config/Makefile.am:
* config/cygwin.m4: remove special cygwin tests
* configure.ac: check for shlwapi and gdi32 libraries (needed in
windows); do not check special cygwin features.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@13841 a592a061-630c-0410-9148-cb99ea01b6c8
browsebox is not build anymore and commented out in bulletsmodule
bullets are disabled in documentdialog: wasn't working before either
remove qt3support!
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@13809 a592a061-630c-0410-9148-cb99ea01b6c8
