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.
Recent gcc versions return a short version with -dumpversion, e.g. 9.
In this case, use -dumpfullversion, which gives something like 9.1.0.
This makes the gcc 9 detection work properly.
The warning about unneeded std::move can be solved by conditioning on
C++14 mode.
The warnings about deprecated copy is harder, so we disable it for
now. We will be able to fix our part, but Qt triggers it a lot too.
When callback printing is enabled, link lyx with -rdynamic, so that
stacks have LyX symbols available.
Add option --disable-callstack-printing to configure.
Running "size" on binary:
* with callstack printing support
text data bss dec hex filename
20891684 34680 107796 21034160 140f4b0 src/lyx
* without callstack printing support
text data bss dec hex filename
17953640 34648 107796 18096084 1141fd4 src/lyx
Until now, building with Qt5 required using --enable-qt5.
This is no more necessary. To build with Qt4 one should now
use --disable-qt5 or, equivalently, --enable-qt5=no.
A function that returns a vector<string> will lead to a crash if the
main code and the library have not been compiled with the same
stdlib-debug state. See for example:
https://stackoverflow.com/questions/4764048/stl-and-release-debug-library-mess
This is fixed by introducing a new variable STDLIB_DEBUG that contains
the flags that trigger the debug mode (autoconf only for now).
This will allow to go forward with bug #10547.
Traditionally LyX behaves differently when the directive DEVEL_VERSION
is defined at compile time. This covers
* more detailed description of current position in status bar
* the help files are open in read/write mode
* more detailed debug output in the View Source panel
This patch introduces the new function devel-mode-toggle that allows
to use devel mode in stable releases, and vice versa.
The information is saved in the session file. The default is to
disable devel mode.
Remove all traces of DEVEL_VERSION in autoconf and cmake
Now configure searches in this order
1. system-installed library
2. code bundled with LyX
If --with-included-mythes or if no mythes library is installed, then
the script selects the bundled version. There should be no cases
leading to error message.
Use the bundled mythes by default again, since the current situaiton
create an error for anybody who does not have the system one
installed.
This is a stop gap measure and I'll return to it later (in a hurry now).
The configure code suggests that the default for
--with-included-(iconv|zlib|hunspell) is "yes", which is wrong: by
default is indeed to use the system libraries.
Change the MyThes detection to use the system version by default.
Also add to the verison information a line which lists the bundled libraries.
The test is stolen from cmake code.
Tested on:
* ubuntu 12.04 with g++ 4.6, clang 3.3 (with libstdc++)
* ubuntu 16.04 with g++ 5.3, clang 3.7 (with libstdc++) and clang 3.7
(with libc++)
The last combination fails, but it seems to be related to real bugs
(reported for debian), so this is OK.
The test file is stolen from cmake. The options tested are, from the
most desirable to the least desirable:
-std=c++14 -std=c++11 "" -std=c++0x -std=gnu++14 -std=gnu++11 -std=gnu++0x
It is expected that the result will not be correct for cygwin, but
this is fixable.
The version is read by checking the macros __clang_major__,
__clang_minor__ and __clang_patchlevel__. Hopefully they will have
coherent values everywhere.
For now, the version is used to set warnings a bit more reasonably for
older clang versions, which do not support -Wdeprecated-register and
some others that are used in pragmas in boost.
This removes many warnings when compiling with clang 3.3.
We only link against boost libraries if we do not use std::regex.
Therefore, we do not need to test how to link against boost libs unconditionally.
Also, the warning regarding stdlib-debug is only needed if we link against boost.
