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.
In particular, the directory frontends/qt4 is renamed to frontends/qt.
Many configurations file have to be updated. All mentions of qt4 in
the source have been audited, and changed to qt if necessary.
The only part that has not been updated is the CMake build system.
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.
Python 3.x shall have priority over python 2.x. In 2.5.0dev, support
for python2 will be removed.
Now, we ignore all pythonx.y names, which are not relevant, and do not try
either the basic "python" name.
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.
