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.
As of enchant 2.x, it is required to create a Broker instance instead
of relying on a static one provided by the library.
Add autoconf and cmake (courtesy of Kornel) tests that check whether
one can indeed instantiate a Broker object, and act on the result in a
new broker() helper function.
Fixes bug #10986.
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.
They moved the QT_QPA_DEFAULT_PLATFORM_NAME definition to the newly
introduced qtgui-config.h header.
This fix is also necessary for cmake, but I don't know how to do it.
It would be simply a matter of using QtGui/qtgui-config.h instead
of QtCore/qconfig.h, if QtGui/qtgui-config.h exists.
The full path of the tools is retained only if the Qt directory is
specified using --with-qt-dir. Now, when qtchooser was detected it
was blindly assumed that the corresponding system tools were being
used. These tools discriminate between Qt4 and Qt5 through the
option -qt=qt4 or -qt=qt5. However, the original Qt tools don't
understand these options, so that if they come first in the PATH,
configuration fails. So, only use those options if we are reasonably
sure that the system Qt is wanted. This is achieved by comparing the
paths of qtchooser and tools as, typically, they are located in the
same directory. In this way, if one prepends the bin directory of a
custom Qt build to PATH (and accordingly adjusts PKG_CONFIG_PATH),
configuration succeeds even if --with-qt-dir is not specified.
With both Qt4 and Qt5, when using a click-to-focus policy, the first
attempt to paste a selection by middle mouse in an external application
which has no focus may fail. It is not clear why this succeeds for some
applications and fails for others, but refreshing the timestamp of the
selection request cures the issue. The cmake part is by Kornel.
See also this thread:
http://thread.gmane.org/gmane.editors.lyx.devel/162491
If the Qt directory is specified by --with-qt-dir, the full path
of the tools is retained. Otherwise, if qtchooser is detected,
the generic names are attempted with proper arguments to select
the desired Qt version. Otherwise, the generic names with and without
proper suffixes (either -qt5 or -qt4) are checked in the PATH.
This means that --with-qt-dir=qtdir should be used only if the tools
are not in the PATH, or qtdir/bin/{moc,rcc,uic} are the right versions
for the desired Qt. In any case, it is later checked that the selected
tools are the right ones and a warning is issued if there is a mismatch.
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.
