Re: [LyX/master] On Linux show in crash message box the backtrace
On Sat, Jun 14, 2014 at 5:26 AM, Peter Kümmel wrote: > commit 2f17858115247a1f2b9e341e7cbe96148911c1ad > Author: Peter Kümmel > Date: Sat Jun 7 11:12:31 2014 +0200 > > On Linux show in crash message box the backtrace Would this be easy to extend to show the backtrace on assertions also? Scott
Changing key bindings in the GUI
Hi all, I want to check whether this is a bug or I'm just missing something. I am using a custom bindings file that calls two other files. The file looks like this: ## \bind_file aqua.bind \bind_file mac.bind \bind "C-y""layout Numbered Examples (consecutive)" \bind"C-~S-a""layout Subexample" \bind"C-/""inset-vspace-bigskip" ## These three custom key bindings work without a problem. The problem is with the daughter bindings files, and I tried to change it through the GUI but to no avail. One of the key bindings in the mac.bind file in the lyx.app folder defines the depth-decrement key binding as: \bind "M-C-Right""depth-increment" But this does not show up when I look in the LyX: Preferences editing shortcuts. There, depth-decrement is not shown to have any key bindings associated with it, and when I clicked on 'modify', the cell for entering the key binding is grayed out. I thought it was a key combination conflict between the aqua and mac bindings files, but I don't see one when I inspect the files. So, I guess I wonder why the mac.bind definition is not working, and why the GUI menu for changing the key bindings is not available. Maria
Re: QUESTION: How to enable Qt5 for LyX master
Am 25.08.2014 um 19:58 schrieb Enrico Forestieri : > On Mon, Aug 25, 2014 at 05:54:08PM +0200, Enrico Forestieri wrote: > >> On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote: >> >>> >>> Am 25.08.2014 um 16:12 schrieb Kornel Benko : >>> Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko > At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 > compilation. > To be more specific FindQt4.cmake: We should check for Q_WS_X11, but assign variable Q_OS_X11. >>> >>> Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within >>> Qt5 >>> either. >> >> Not only that. Some of the Q_WS_WIN guards should not be replaced at all, >> othewise it will not compile with Qt5. For example, the QWindowsMime class >> is not available anymore and, until they make it available again, that >> guard should not be replaced. So, I suggest to replace the guards only >> if you are able to check the result. >> >> Another side effect is that my Qt5 port for cygwin will require its own >> guard now that Q_WS_WIN is not available anymore. I wonder what they were >> drinking when that decision was taken... > > I went ahead and replaced almost all occurrences of Q_WS_WIN as appropriate > for Qt5. The remaining ones are those related to code that doesn't compile > on Qt5, ATM. Ok, I did it for Q_WS_MACX now. Stephan
Re: QUESTION: How to enable Qt5 for LyX master
On Mon, Aug 25, 2014 at 05:54:08PM +0200, Enrico Forestieri wrote: > On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote: > > > > > Am 25.08.2014 um 16:12 schrieb Kornel Benko : > > > > > Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko > > > > > >> At least on QT4 there is no symbol Q_OS_X11. So this patch would break > > >> QT4 > > >> compilation. > > >> > > > > > > To be more specific > > > > > > FindQt4.cmake: > > > We should check for Q_WS_X11, but assign variable Q_OS_X11. > > > > Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within > > Qt5 > > either. > > Not only that. Some of the Q_WS_WIN guards should not be replaced at all, > othewise it will not compile with Qt5. For example, the QWindowsMime class > is not available anymore and, until they make it available again, that > guard should not be replaced. So, I suggest to replace the guards only > if you are able to check the result. > > Another side effect is that my Qt5 port for cygwin will require its own > guard now that Q_WS_WIN is not available anymore. I wonder what they were > drinking when that decision was taken... I went ahead and replaced almost all occurrences of Q_WS_WIN as appropriate for Qt5. The remaining ones are those related to code that doesn't compile on Qt5, ATM. -- Enrico
Re: QUESTION: How to enable Qt5 for LyX master
Am 25.08.2014 um 17:54 schrieb Enrico Forestieri : > On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote: > >> >> Am 25.08.2014 um 16:12 schrieb Kornel Benko : >> >>> Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko >>> At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 compilation. >>> >>> To be more specific >>> >>> FindQt4.cmake: >>> We should check for Q_WS_X11, but assign variable Q_OS_X11. >> >> Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 >> either. > > Not only that. Some of the Q_WS_WIN guards should not be replaced at all, > othewise it will not compile with Qt5. For example, the QWindowsMime class > is not available anymore and, until they make it available again, that > guard should not be replaced. So, I suggest to replace the guards only > if you are able to check the result. Ok, I'll do it then this way. Thanks. > Another side effect is that my Qt5 port for cygwin will require its own > guard now that Q_WS_WIN is not available anymore. I wonder what they were > drinking when that decision was taken… +1 Stephan > > -- > Enrico
Re: [LyX/master] Fix the -geometry command line argument for Windows.
On 08/25/2014 01:09 PM, Enrico Forestieri wrote: On Mon, Aug 25, 2014 at 01:06:34PM -0400, Richard Heck wrote: We are string frozen at the moment. No string changes here? Yes, no string is changed. OK, then. rh
Re: [LyX/master] Fix the -geometry command line argument for Windows.
On Mon, Aug 25, 2014 at 01:06:34PM -0400, Richard Heck wrote: > > We are string frozen at the moment. No string changes here? Yes, no string is changed. -- Enrico
Re: [LyX/master] Fix the -geometry command line argument for Windows.
On 08/25/2014 01:01 PM, Enrico Forestieri wrote: On Mon, Aug 25, 2014 at 06:54:05PM +0200, Enrico Forestieri wrote: commit 565260126eb106ab00049285627417e73736bb96 Author: Enrico Forestieri Date: Mon Aug 25 18:35:15 2014 +0200 Fix the -geometry command line argument for Windows. The command line argument -geometry WIDTHxHEIGHT±XOFF±YOFF specifies a preferred size and location for the main window. Currently, this is semi-broken on Windows. Indeed, only specifying WIDTH and HEIGHT places the main window such that the left and top borders are invisible such that the window cannot be moved. Moreover, the XOFF and YOFF parts (when present) are used to specify the distance of the window from the left and top or right and bottom edges of the screen, when using '+' or '-', respectively. However, -geometry 800x600-20-20, instead of placing the window such that its bottom and right edges are at a distance of 20 pixels from the corresponding screen edges, places the window such that its left and top borders are out of the screen. This is corrected by this commit, which also addresses the fact that Qt5 does not define Q_WS_WIN anymore. Richard, may I apply this to the stable branch? We are string frozen at the moment. No string changes here? Richard
Re: [LyX/master] Fix the -geometry command line argument for Windows.
On Mon, Aug 25, 2014 at 06:54:05PM +0200, Enrico Forestieri wrote:
> commit 565260126eb106ab00049285627417e73736bb96
> Author: Enrico Forestieri
> Date: Mon Aug 25 18:35:15 2014 +0200
>
> Fix the -geometry command line argument for Windows.
>
> The command line argument -geometry WIDTHxHEIGHT±XOFF±YOFF
> specifies a preferred size and location for the main window.
> Currently, this is semi-broken on Windows. Indeed, only
> specifying WIDTH and HEIGHT places the main window such that
> the left and top borders are invisible such that the window cannot
> be moved. Moreover, the XOFF and YOFF parts (when present) are
> used to specify the distance of the window from the left and top
> or right and bottom edges of the screen, when using '+' or '-',
> respectively. However, -geometry 800x600-20-20, instead of placing
> the window such that its bottom and right edges are at a distance
> of 20 pixels from the corresponding screen edges, places the
> window such that its left and top borders are out of the screen.
> This is corrected by this commit, which also addresses the fact
> that Qt5 does not define Q_WS_WIN anymore.
Richard, may I apply this to the stable branch?
(Minus the Qt5 part, of course)
> diff --git a/src/frontends/qt4/GuiApplication.cpp
> b/src/frontends/qt4/GuiApplication.cpp
> index 56cbd60..64c645d 100644
> --- a/src/frontends/qt4/GuiApplication.cpp
> +++ b/src/frontends/qt4/GuiApplication.cpp
> @@ -87,6 +87,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2193,16 +2194,40 @@ void GuiApplication::createView(QString const &
> geometry_arg, bool autoShow,
> }
>
> if (!geometry_arg.isEmpty()) {
> -#ifdef Q_WS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_CYGWIN_WIN)
> int x, y;
> int w, h;
> - QRegExp re( "[=]*(?:([0-9]+)[xX]([0-9]+)){0,1}[
> ]*(?:([+-][0-9]*)([+-][0-9]*)){0,1}" );
> + QChar sx, sy;
> + QRegExp re( "[=]*(?:([0-9]+)[xX]([0-9]+)){0,1}[
> ]*(?:([+-][0-9]*)){0,1}(?:([+-][0-9]*)){0,1}" );
> re.indexIn(geometry_arg);
> w = re.cap(1).toInt();
> h = re.cap(2).toInt();
> x = re.cap(3).toInt();
> y = re.cap(4).toInt();
> + sx = re.cap(3).isEmpty() ? '+' : re.cap(3).at(0);
> + sy = re.cap(4).isEmpty() ? '+' : re.cap(4).at(0);
> + // Set initial geometry such that we can get the frame size.
> view->setGeometry(x, y, w, h);
> + int framewidth = view->geometry().x() - view->x();
> + int titleheight = view->geometry().y() - view->y();
> + // Negative displacements must be interpreted as distances
> + // from the right or bottom screen borders.
> + if (sx == '-' || sy == '-') {
> + QRect rec = QApplication::desktop()->screenGeometry();
> + if (sx == '-')
> + x += rec.width() - w - framewidth;
> + if (sy == '-')
> + y += rec.height() - h - titleheight;
> + view->setGeometry(x, y, w, h);
> + }
> + // Make sure that the left and top frame borders are visible.
> + if (view->x() < 0 || view->y() < 0) {
> + if (view->x() < 0)
> + x = framewidth;
> + if (view->y() < 0)
> + y = titleheight;
> + view->setGeometry(x, y, w, h);
> + }
> #endif
> }
> view->setFocus();
--
Enrico
Re: QUESTION: How to enable Qt5 for LyX master
On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote: > > Am 25.08.2014 um 16:12 schrieb Kornel Benko : > > > Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko > > > >> At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 > >> compilation. > >> > > > > To be more specific > > > > FindQt4.cmake: > > We should check for Q_WS_X11, but assign variable Q_OS_X11. > > Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 > either. Not only that. Some of the Q_WS_WIN guards should not be replaced at all, othewise it will not compile with Qt5. For example, the QWindowsMime class is not available anymore and, until they make it available again, that guard should not be replaced. So, I suggest to replace the guards only if you are able to check the result. Another side effect is that my Qt5 port for cygwin will require its own guard now that Q_WS_WIN is not available anymore. I wonder what they were drinking when that decision was taken... -- Enrico
Warnings due to x***arrow commit
CXX InsetMathXArrow.o
../../src/mathed/InsetMathXArrow.cpp: In member function 'virtual void
lyx::InsetMathXArrow::mathmlize(lyx::MathStream&) const':
../../src/mathed/InsetMathXArrow.cpp:116:8: warning: 'arrow' may be used
uninitialized in this function [-Wmaybe-uninitialized]
<< arrow << cell(1) << cell(0)
^
../../src/mathed/InsetMathXArrow.cpp: In member function 'virtual void
lyx::InsetMathXArrow::htmlize(lyx::HtmlStream&) const':
../../src/mathed/InsetMathXArrow.cpp:157:43: warning: 'arrow' may be
used uninitialized in this function [-Wmaybe-uninitialized]
<< MTag("span", "class='xabottom'") << arrow << ETag("span")
Re: [LyX/master] Fix bug with wrong baseline calculation in last paragraph
On Mon, Aug 25, 2014 at 8:28 AM, Jürgen Spitzmüller wrote:
> Am Samstag 23 August 2014, 08:10:45 schrieb Scott Kostyshak:
>> This commit seems ('git bisect run' tells me. I have not confirmed) to
>> have broken export of the Japanese beamer manual to DVI. I think it
>> also breaks two other tests:
>> 3632 - export/examples/ja/beamer_pdf (Failed)
>> 3634 - export/examples/ja/beamer_pdf3 (Failed)
>
> Thanks. Could you file a new report for this? I am quite busy ATM but will
> have
> a look at it eventually.
Sure, I created it at #9250. Let me know if you cannot get to it
before 2.1.2 and I will fix the document manually.
Scott
Re: QUESTION: How to enable Qt5 for LyX master
Am 25.08.2014 um 16:12 schrieb Kornel Benko : > Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko >> Am Montag, 25. August 2014 um 15:53:14, schrieb Stephan Witt >> >>> Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore. >>> The reasoning is to disable all platform specific code and force the Qt >>> users >>> like us to review all code guarded by Q_WS_ macros. This means all code in >>> LyX >>> inside these ifdef's is not compiled and executed anymore with Qt5. >>> >>> My question now is: should we simply replace all Q_WS_ macros with the >>> corresponding Q_OS_ macro for all platforms or should this be done for every >>> platform in separate steps? >>> >>> The first patch does this for all platforms - in case someone wants to test >>> it too. >>> The second one is for Mac OS X only. I'll plan to commit the second one if >>> I don't >>> get enough encouraging feedback for the first one. >>> >>> With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6. >>> >>> Stephan >> >> At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 >> compilation. >> > > To be more specific > > FindQt4.cmake: > We should check for Q_WS_X11, but assign variable Q_OS_X11. Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 either. Stephan
Re: QUESTION: How to enable Qt5 for LyX master
Am Montag, 25. August 2014 um 15:53:14, schrieb Stephan Witt > Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore. > The reasoning is to disable all platform specific code and force the Qt users > like us to review all code guarded by Q_WS_ macros. This means all code in LyX > inside these ifdef's is not compiled and executed anymore with Qt5. > > My question now is: should we simply replace all Q_WS_ macros with the > corresponding Q_OS_ macro for all platforms or should this be done for every > platform in separate steps? > > The first patch does this for all platforms - in case someone wants to test > it too. > The second one is for Mac OS X only. I'll plan to commit the second one if I > don't > get enough encouraging feedback for the first one. > > With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6. > > Stephan At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 compilation. Kornel signature.asc Description: This is a digitally signed message part.
Re: QUESTION: How to enable Qt5 for LyX master
Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko > Am Montag, 25. August 2014 um 15:53:14, schrieb Stephan Witt > > Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore. > > The reasoning is to disable all platform specific code and force the Qt > > users > > like us to review all code guarded by Q_WS_ macros. This means all code in > > LyX > > inside these ifdef's is not compiled and executed anymore with Qt5. > > > > My question now is: should we simply replace all Q_WS_ macros with the > > corresponding Q_OS_ macro for all platforms or should this be done for every > > platform in separate steps? > > > > The first patch does this for all platforms - in case someone wants to test > > it too. > > The second one is for Mac OS X only. I'll plan to commit the second one if > > I don't > > get enough encouraging feedback for the first one. > > > > With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6. > > > > Stephan > > At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 > compilation. > To be more specific FindQt4.cmake: We should check for Q_WS_X11, but assign variable Q_OS_X11. Kornel signature.asc Description: This is a digitally signed message part.
Re: QUESTION: How to enable Qt5 for LyX master
Am 25.08.2014 um 15:53 schrieb Stephan Witt : > Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore. > The reasoning is to disable all platform specific code and force the Qt users > like us to review all code guarded by Q_WS_ macros. This means all code in LyX > inside these ifdef's is not compiled and executed anymore with Qt5. > > My question now is: should we simply replace all Q_WS_ macros with the > corresponding Q_OS_ macro for all platforms or should this be done for every > platform in separate steps? > > The first patch does this for all platforms - in case someone wants to test > it too. > The second one is for Mac OS X only. I'll plan to commit the second one if I > don't > get enough encouraging feedback for the first one. > > With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6. > > Stephan > > <2014-08-25-Qt5-all-platforms.patch><2014-08-25-Qt5-mac-platform.patch> Sorry for the noise regarding X11 - I see now Q_WS_X11 shouldn't be replaced. Since only a limited count of lyx devs is able to compile and run windows I'd guess I stick with the second patch - change it for Mac OS only. Stephan
QUESTION: How to enable Qt5 for LyX master
Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore. The reasoning is to disable all platform specific code and force the Qt users like us to review all code guarded by Q_WS_ macros. This means all code in LyX inside these ifdef's is not compiled and executed anymore with Qt5. My question now is: should we simply replace all Q_WS_ macros with the corresponding Q_OS_ macro for all platforms or should this be done for every platform in separate steps? The first patch does this for all platforms - in case someone wants to test it too. The second one is for Mac OS X only. I'll plan to commit the second one if I don't get enough encouraging feedback for the first one. With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6. Stephan 2014-08-25-Qt5-all-platforms.patch Description: Binary data 2014-08-25-Qt5-mac-platform.patch Description: Binary data
Re: [LyX/master] Fix bug with wrong baseline calculation in last paragraph
Am Samstag 23 August 2014, 08:10:45 schrieb Scott Kostyshak:
> This commit seems ('git bisect run' tells me. I have not confirmed) to
> have broken export of the Japanese beamer manual to DVI. I think it
> also breaks two other tests:
> 3632 - export/examples/ja/beamer_pdf (Failed)
> 3634 - export/examples/ja/beamer_pdf3 (Failed)
Thanks. Could you file a new report for this? I am quite busy ATM but will have
a look at it eventually.
Jürgen
Re: LyX+Qt5 build (CMake+XCode) on OS X
Sent from my iPad
> On 25 Aug 2014, at 07:55, Stephan Witt wrote:
>
>> Am 23.08.2014 um 18:01 schrieb Patrick De Visschere :
>>
>>> On 23 Aug, 2014, at 14:50 , Stephan Witt wrote:
>>>
Am 23.08.2014 um 12:01 schrieb Patrick De Visschere
:
> On 20 Aug, 2014, at 23:15 , Stephan Witt wrote:
>
>> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere
>> :
>>
>>> On 20 Aug, 2014, at 11:22 , Stephan Witt wrote:
>>>
Am 19.08.2014 um 22:41 schrieb Patrick De Visschere
:
> On 19 Aug, 2014, at 14:12 , Stephan Witt wrote:
>
> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere
> :
My environment
* Mac OS X 10.9.4
* Darwin Kernel Version 13.3.0
* Qt 5.3.1 (stable branch) (default Cocoa)
./configure -opensource -silent -shared -release -no-dbus -nomake
examples -nomake tools -no-framework
>>>
>>> You don't build the libraries as frameworks. I'm not sure if this makes
>>> no difference.
>>>
>>> I'm using the Qt frameworks I've build myself.
>>>
>>> Stephan
>>
>> Stephan,
>>
>> I was planning to do that. (the qt-debug build does not make a
>> difference as you expected)
>>
>> I suppose you use the LyX-Mac-binary-release.sh script.
>>
>> I have never managed to use this script without making changes to it,
>> perhaps because I’m using it the wrong way.
>>
>> I build qt as a framework separately and would then use the script like:
>>
>> sh development/LyX-Mac-binary-release.sh --with-qt-frameworks=yes
>> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1
>> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8
>> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug
>>
>> I think the --with-qt-frameworks=yes is needed to include qt as a
>> framework;
>>
>> and --with-qt-dir=/… points to the dir where the qt-framework has been
>> installed (previously).
>>
>> I’m not sure about the exact meaning of --qt-deployment=yes but I think
>> I need it too.
>>
>> What I don’t understand are the lines 260-262
>> if [ "${configure_qt_frameworks}" != "yes" ]; then
>>QtInstallDir=${QTDIR:-"/opt/qt4"}
>> fi
>>
>> with --with-qt-frameworks=yes, QtInstallDir is not set.
>>
>> Therefore I uncomment the if/fi so that
>> QtInstallDir=${QTDIR:-"/opt/qt4”}
>>
>> is always executed and QtInstallDir points to my qt-install dir.
>>
>> In addition I must modify some CPPFLAGS= ...
>>
>> Any idea what I’m doing wrong?
>>
>> Patrick De Visschere
>
> Perhaps I should remove the --with-qt-frameworks switch. I don't use it
> anymore
> and it was meant as "with the frameworks by Qt (Nokia)". The
> --qt-deployment=yes
> is default and with it the script copies the frameworks to the package.
> This is
> needed if you want to use the LyX app on another system.
>
> I'd avoid the --with-libiconv-prefix=/opt/local switch.
>
> This is the shell script I'm using for calling LyX-Mac-binary-release.sh:
>
> #!/bin/sh
> ARCH=x86_64
> QtVersion=5.3.1
> QtAPI=-cocoa
> LyXVersion=lyx
> CC=cc CXX=c++ \
> QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI}
> QtVersion=${QtVersion} \
> sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \
> --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \
> --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH}
> \
> "$@"
>
> Stephan
I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the
menubar appears immediately. Since with XCode I use the macports iconv
library that could still theoretically be the culprit. Or maybe it’s just
due to Xcode. Anyway this is not very important;
I tried to build (with Xcode) without aspell and hunspell but somehow
cmake doesn’t want that.
>>>
>>> This is my script to call cmake for Xcode project generation:
>>>
>>> #!/bin/sh
>>> export PATH="/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64/bin:${PATH}"
>>> LyxSourceDir="$(pwd)/lyx"
>>> LyxUtilDir="/Users/Shared/LyX/utilities"
>>> CMAKE_GENERATOR="Xcode"
>>> LyXVersion=$(grep AC_INIT "${LyxSourceDir}"/configure.ac | cut -d, -f2 | tr
>>> -d " ()")
>>> LyxBuildDir=lyx-build/cmake/"${LyXVersion}"
>>> if [ -f "${LyxSourceDir}/development/cmake/CMakeLists.txt" ]; then
>>> TOPCMAKE="${LyxSourceDir}/development/cmake"
>>> COPYRESOURCES="yes"
>>> else
>>> TOPCMAKE="${LyxSourceDir}"
>>> fi
>>> rm -rf "${LyxBuildDir}"
>>> mkdir -p "${LyxBuildDir}"
>>>
>>> case "$(qmake -version)" in
>>> *Using*5.*)
>>> LYX_USE_QT="-DLYX_USE_QT=QT5"
>>> esac
>>>
>>> SPELLER_OPTIONS="-DASPEL
