Am So., 22. Okt. 2023 um 21:36 Uhr schrieb Yu Jin:
> It's this on Windows:
>
>
> C:/Qt/6.6.0/msvc2019_64/include/QtCoreC:/Qt/6.6.0/msvc2019_64/includeC:/Qt/6.6.0/msvc2019_64/include/QtZlib$<$>:>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0/QtZl
>
> > > > Am Sa., 21. Okt. 2023 um 22:00 Uhr schrieb Yu Jin:
> > > >
> > > > > Am Sa., 21. Okt. 2023 um 19:42 Uhr schrieb Kornel Benko:
> > > > >
> > > > >>
> > > > >> What bothers me, is that the following config
> Am Sa., 21. Okt. 2023 um 19:42 Uhr schrieb Kornel Benko:
> > > >
> > > >>
> > > >> What bothers me, is that the following configure is OK.
> > > >> For me that implies that the first configure already created
> > > >
;>
> > >> What bothers me, is that the following configure is OK.
> > >> For me that implies that the first configure already created
> > >> CMakeCache.txt.
> > >> Could you compare the first CMakeCache.txt with later created version?
> > >&
Am Sun, 22 Oct 2023 10:22:54 +0200
schrieb Yu Jin :
> Am Sa., 21. Okt. 2023 um 22:00 Uhr schrieb Yu Jin :
>
> > Am Sa., 21. Okt. 2023 um 19:42 Uhr schrieb Kornel Benko:
> >
> >>
> >> What bothers me, is that the following configure is OK.
> >> For me
Am Sa., 21. Okt. 2023 um 22:00 Uhr schrieb Yu Jin :
> Am Sa., 21. Okt. 2023 um 19:42 Uhr schrieb Kornel Benko:
>
>>
>> What bothers me, is that the following configure is OK.
>> For me that implies that the first configure already created
>> CMakeCache.txt.
Am Sa., 21. Okt. 2023 um 19:42 Uhr schrieb Kornel Benko:
>
> What bothers me, is that the following configure is OK.
> For me that implies that the first configure already created
> CMakeCache.txt.
> Could you compare the first CMakeCache.txt with later created version?
>
6.6.0/msvc2019_64/include;C:/Qt/6.6.0/msvc2019_64/include/QtZlib;$<$>:>;$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0>;$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0/QtZlib>
>
> Is this something variable specified by CMake or can we affect it? Maybe
Am Sa., 21. Okt. 2023 um 08:42 Uhr schrieb Yu Jin :
> Am So., 15. Okt. 2023 um 22:32 Uhr schrieb Yu Jin >:
>
>> Am Mo., 2. Okt. 2023 um 21:51 Uhr schrieb Yu Jin:
>>
>>>
>>> C:\Qt\6.5.2\msvc2019_64\include\QtGui\qtgui-config.h
>>>
>>
>> Ping...
>> I don't really understand what is wrong here, coul
Am So., 15. Okt. 2023 um 22:32 Uhr schrieb Yu Jin :
> Am Mo., 2. Okt. 2023 um 21:51 Uhr schrieb Yu Jin:
>
>>
>> C:\Qt\6.5.2\msvc2019_64\include\QtGui\qtgui-config.h
>>
>
> Ping...
> I don't really understand what is wrong here, could some1 help out with a
> minimal example so I can ask the Qt foru
Am Mo., 2. Okt. 2023 um 21:51 Uhr schrieb Yu Jin:
>
> C:\Qt\6.5.2\msvc2019_64\include\QtGui\qtgui-config.h
>
Ping...
I don't really understand what is wrong here, could some1 help out with a
minimal example so I can ask the Qt forum?
--
Eugene
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
Am Sa., 30. Sept. 2023 um 13:45 Uhr schrieb Kornel Benko:
> Am Sat, 30 Sep 2023 09:35:57 +0200
> schrieb Yu Jin:
>
> > Am So., 17. Sept. 2023 um 07:24 Uhr schrieb Yu Jin:
> >
> > > Am So., 17. Sept. 2023 um 07:23 Uhr schrieb Yu Jin
> > > >:
> > &g
Am Sat, 30 Sep 2023 09:35:57 +0200
schrieb Yu Jin :
> Am So., 17. Sept. 2023 um 07:24 Uhr schrieb Yu Jin :
>
> > Am So., 17. Sept. 2023 um 07:23 Uhr schrieb Yu Jin > >:
> >
> >> When I configure for the first time (into an empty folder) I get this
> >&
Am So., 17. Sept. 2023 um 07:24 Uhr schrieb Yu Jin :
> Am So., 17. Sept. 2023 um 07:23 Uhr schrieb Yu Jin >:
>
>> When I configure for the first time (into an empty folder) I get this
>> error:
>>
>> CMake Error at
>> C:/lyx/master-build-64-qt6/CM
Am So., 17. Sept. 2023 um 07:23 Uhr schrieb Yu Jin :
> When I configure for the first time (into an empty folder) I get this
> error:
>
> CMake Error at
> C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-re0snf/CMakeLists.txt:12
> (include_directories):
> Error
When I configure for the first time (into an empty folder) I get this error:
CMake Error at
C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-re0snf/CMakeLists.txt:12
(include_directories):
Error evaluating generator expression:
$
Target "Qt6::ZlibPrivate" not fou
On Mon, Jul 17, 2023 at 09:34:40PM +0200, Jean-Marc Lasgouttes wrote:
Moreover, I think that the Qt4 version would need a different
approach, even if the info can be obtained by qmake. I recall that
André even put up a build system based on qmake ;)
The good thing about Qt4 is that we remove
Le 17/07/2023 à 21:14, Enrico Forestieri a écrit :
Take into account that modules differ from a Qt version to another, so
we would still need 3 different paths.
A helper function with parameters?
Moreover, I think that the Qt4
version would need a different approach, even if the info can be
On Mon, Jul 17, 2023 at 08:59:13PM +0200, Jean-Marc Lasgouttes wrote:
Le 17/07/2023 à 20:56, Enrico Forestieri a écrit :
I expect it to work with Qt5, at least. But why should we do that?
Remember: don't fix it if it ain't broken.
Because the rest is a mess and we have now 3 different paths t
Le 17/07/2023 à 20:56, Enrico Forestieri a écrit :
I expect it to work with Qt5, at least. But why should we do that?
Remember: don't fix it if it ain't broken.
Because the rest is a mess and we have now 3 different paths to do the
same thing. Are there known cases where qmake is not enough fo
On Mon, Jul 17, 2023 at 03:56:40PM +0200, Jean-Marc Lasgouttes wrote:
This is great. Concerning replacing most of the qt.m4 code with the
qmake-based solution, would you expect it to work? This is post-2.4,
of course.
I expect it to work with Qt5, at least. But why should we do that?
Remembe
Le 15/07/2023 à 15:31, Enrico Forestieri a écrit :
On Sat, Jul 15, 2023 at 01:47:56PM +0200, Jean-Marc Lasgouttes wrote:
Le 15/07/2023 à 13:44, Enrico Forestieri a écrit :
It suffices replacing LYX_WARNING with AC_MSG_ERROR. However, in this
case configure stops there.
This is whaty we do
On Sat, Jul 15, 2023 at 01:47:56PM +0200, Jean-Marc Lasgouttes wrote:
Le 15/07/2023 à 13:44, Enrico Forestieri a écrit :
It suffices replacing LYX_WARNING with AC_MSG_ERROR. However, in
this case configure stops there.
This is whaty we do now if Qt cannot beconfigure properly. Warnings
are
This looks good (I did not try it yet). The warning at the end should
be an error, right?
It suffices replacing LYX_WARNING with AC_MSG_ERROR. However, in this
case configure stops there.
This is whaty we do now if Qt cannot beconfigure properly. Warnings are
for cases where people can co
ng at the end should
be an error, right?
It suffices replacing LYX_WARNING with AC_MSG_ERROR. However, in this
case configure stops there.
--
Enrico
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Le 15/07/2023 à 00:50, Enrico Forestieri a écrit :
We want to fail in some way when there is no svg, not build without
it, don't we?
Yep. What about the attached?
This looks good (I did not try it yet). The warning at the end should be
an error, right?
JMarc
--
lyx-devel mailing list
lyx-
On Fri, Jul 14, 2023 at 11:12:33PM +0200, Jean-Marc Lasgouttes wrote:
Le 14/07/2023 à 21:42, Enrico Forestieri a écrit :
I see (or maybe not). Next question is: why is fake custom target
names %?
Because that defines a dynamic target in a makefile:
https://stackoverflow.com/questions/740/
Le 14/07/2023 à 21:42, Enrico Forestieri a écrit :
I see (or maybe not). Next question is: why is fake custom target
names %?
Because that defines a dynamic target in a makefile:
https://stackoverflow.com/questions/740/what-does-a-percent-symbol-do-in-a-makefile
Thanks! I still have to un
On Fri, Jul 14, 2023 at 08:48:07PM +0200, Jean-Marc Lasgouttes wrote:
Le 14/07/2023 à 20:32, Enrico Forestieri a écrit :
There is nothing special about naming percent a variable and that is
simply done because the fake custom target is named "%". See here:
https://doc.qt.io/qt-6/qmake-advanced
Le 14/07/2023 à 20:32, Enrico Forestieri a écrit :
There is nothing special about naming percent a variable and that is
simply done because the fake custom target is named "%". See here:
https://doc.qt.io/qt-6/qmake-advanced-usage.html#adding-custom-targets
I see (or maybe not). Next question
On Wed, Jul 12, 2023 at 10:06:15PM +0200, Jean-Marc Lasgouttes wrote:
Le 12/07/2023 à 21:39, Enrico Forestieri a écrit :
I think that the qmake code could be adapted to issue such warnings.
I will have a look if nobody beats me to it.
To be frank, I'd love to be able to dispose of most of the
Le 12/07/2023 à 21:39, Enrico Forestieri a écrit :
I think that the qmake code could be adapted to issue such warnings. I
will have a look if nobody beats me to it.
To be frank, I'd love to be able to dispose of most of the stuff in
qt.m4 and rely on qmake only. I have to say though that the c
On Tue, Jul 11, 2023 at 11:20:30PM +0200, Jean-Marc Lasgouttes wrote:
Le 24/05/2023 à 15:48, lorenzobertin...@gmail.com a écrit :
Dear list,
today I run ./configure to start a Qt6 build and it went through
without problems. The build then failed with:
In file included from Dialog.cpp:15
Le 24/05/2023 à 15:48, lorenzobertin...@gmail.com a écrit :
Dear list,
today I run ./configure to start a Qt6 build and it went through
without problems. The build then failed with:
In file included from Dialog.cpp:15:
GuiView.h:25:10: fatal error: QSvgWidget: File o directory non
esistente
Dear list,
today I run ./configure to start a Qt6 build and it went through
without problems. The build then failed with:
> In file included from Dialog.cpp:15:
> GuiView.h:25:10: fatal error: QSvgWidget: File o directory non
> esistente
>2
Le 08/11/2022 à 23:06, Jean-Marc Lasgouttes a écrit :
commit 9fc89762ee731daa36092c598028e0b95afc69f2
Author: Jean-Marc Lasgouttes
Date: Fri Jun 24 13:27:55 2022 +0200
Fix configure script with autoconf 2.71
Not a backport, but related to e4416535.
Pushing this was not
On Sun, Jan 23, 2022 at 04:06:07PM +, José Abílio Matos wrote:
> Could it be a cache interfering?
> Are the previewed files cached?
I don't think so. I also checked whether missing reconfigure could have been
the case, but it does not look like that either.
Last thing coming to my mind is that
On Sunday, 23 January 2022 15.01.33 WET Pavel Sanda wrote:
> On Sat, Jan 22, 2022 at 09:54:39PM +, José Abílio Matos wrote:
> > The problem here is that the placeholder is not replaced before being
used.
> > In order to see what python is being used you can see:
> >
> > Help->About LyX
>
> p
On Sat, Jan 22, 2022 at 09:54:39PM +, José Abílio Matos wrote:
> The problem here is that the placeholder is not replaced before being used.
> In order to see what python is being used you can see:
>
> Help->About LyX
python3 -tt
> In a hunch does the attached patch fixes the issue?
> The id
On Saturday, 22 January 2022 19.49.26 WET Pavel Sanda wrote:
> Hi Jose,
>
> this what I see in curent master:
> 1. start lyx
> 2. load file
> 3. this is what I see in terminal window:
> env: '$${python}': No such file or directory
>
> Most likely related to image preview conversions, this what I
On Tue, Jan 04, 2022 at 12:52:37AM +0100, JosĂŠ Matos wrote:
> commit 109ea2be4a21ca93d22ab25703b3352a50fbbe3b
> Author: José Matos
> Date: Tue Jan 4 00:21:34 2022 +
>
> Add new placeholder $${python} to configure
>
> This ensures that we use a consistent
for Mac package with automatic
>> Qt-version based detection plus configure option to choose it manually
>
> I can't compile on Linux anymore…
Yes, I forgot to care for appropriate guards.
Is it better now?
Stephan
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Wed, Dec 04, 2019 at 08:24:42PM +0100, Kornel Benko wrote:
> Am Wed, 4 Dec 2019 12:22:09 -0500
> schrieb Scott Kostyshak :
>
> > /home/scott/lyxbuilds/master/repo/src/HunspellChecker.cpp:362:43: error:
> > ‘int
> > Hunspell::spell(const char*, int*, char**)’ is deprecated
> > [-Werror=deprecat
Am Wed, 4 Dec 2019 12:22:09 -0500
schrieb Scott Kostyshak :
> /home/scott/lyxbuilds/master/repo/src/HunspellChecker.cpp:362:43: error: ‘int
> Hunspell::spell(const char*, int*, char**)’ is deprecated
> [-Werror=deprecated-declarations] 362 | if (h->spell(word_to_check.c_str(),
> &info))
> |
On Thu, Nov 28, 2019 at 02:17:35PM +0100, Kornel Benko wrote:
> commit 9de4b9ab34e07d50a85c555f2bdfa91713812f4b
> Author: Kornel Benko
> Date: Thu Nov 28 14:31:26 2019 +0100
>
> Cmake build: Remove unneeded hunspell path from configure test
>
> Spotted
On Tuesday, 15 May 2018 11.03.01 WEST Jean-Marc Lasgouttes
wrote:
> This has been fixed by Enrico at 6253cc4c51e4e3, right?
>
> JMarc
After running again autogen.sh the problem went away. So I
suspect that the answer is yes to your question. :-)
--
José Abílio
Le 08/05/2018 à 16:08, José Abílio Matos a écrit :
=== The following minor problems have been detected by configure.
=== Please check the messages below before running 'make'.
=== (see the section 'Problems' in the INSTALL file)
== The found moc compiler is for Qt moc-q
$ ~/lyx/lyx/configure --enable-qt5
...
Configuration
Host type: x86_64-unknown-linux-gnu
Special build flags: build=development warnings assertions stdlib-debug
C++ Compiler:g++ (8)
C++ Compiler flags: -Wall -Wextra -Wfloat-conversion -fPIC -g -O
C
On Mon, Mar 19, 2018 at 9:45 AM, Jean-Marc Lasgouttes
wrote:
> Le 19/03/2018 à 16:37, Richard Kimberly Heck a écrit :
>
>> I did that. Thanks for the patch. Riki, I guess this is OK for 2.3.1.
>>> It is too late for 2.2.4 unfortunately.
>>>
>>
>> Yes, good for 2.3.1.
>>
>
> Thanks, done.
>
> JMar
Le 19/03/2018 à 16:37, Richard Kimberly Heck a écrit :
I did that. Thanks for the patch. Riki, I guess this is OK for 2.3.1.
It is too late for 2.2.4 unfortunately.
Yes, good for 2.3.1.
Thanks, done.
JMarc
On 03/19/2018 05:14 AM, Jean-Marc Lasgouttes wrote:
> Le 19/03/2018 à 06:26, Joel Kulesza a écrit :
>>> However, it looks as though autogen.sh was and is
>>> self-inconsistent. Line 14 claims LyX requires automake >=1.14
>>> and Lines 19/23 claimed automake 1.14 or 1.15 were required.
Le 19/03/2018 à 06:26, Joel Kulesza a écrit :
However, it looks as though autogen.sh was and is
self-inconsistent. Line 14 claims LyX requires automake >=1.14
and Lines 19/23 claimed automake 1.14 or 1.15 were required. My
patch only addresses the latter point because I'm not su
;>
>>> Has anyone configured/built with automake-1.16?
>>>
>>> Using homebrew on MacOS, I (apparently though not deliberately)
>>> underwent an upgrade to automake 1.16 and my previous configure/make
>>> process broke. It looks like automake version 1.15
Has anyone configured/built with automake-1.16?
>
> Using homebrew on MacOS, I (apparently though not
> deliberately) underwent an upgrade to automake 1.16 and my
> previous configure/make process broke. It looks like automake
> version
rwent
>> an upgrade to automake 1.16 and my previous configure/make process broke.
>> It looks like automake version 1.15 is hardcoded into the configure script
>> (line 3250 of configure from master@a5c859f8). I'm sure I can repair
>> this, but I wanted to
On Sun, Mar 18, 2018 at 5:19 PM, Joel Kulesza wrote:
> LyX Developers,
>
> Has anyone configured/built with automake-1.16?
>
> Using homebrew on MacOS, I (apparently though not deliberately) underwent
> an upgrade to automake 1.16 and my previous configure/make process brok
LyX Developers,
Has anyone configured/built with automake-1.16?
Using homebrew on MacOS, I (apparently though not deliberately) underwent
an upgrade to automake 1.16 and my previous configure/make process broke.
It looks like automake version 1.15 is hardcoded into the configure script
(line
Le 25/02/2018 à 20:40, Stephan Witt a écrit :
Am 25.02.2018 um 19:57 schrieb José Abílio Matos :
On Sunday, 25 February 2018 16.58.36 WET Stephan Witt wrote:
Today I saw a warning with lyx-2.3.0 as follows:
configure: WARNING: unrecognized options: --enable-cxx11
Hi Stephan,
isn&#
Am 25.02.2018 um 19:57 schrieb José Abílio Matos :
>
> On Sunday, 25 February 2018 16.58.36 WET Stephan Witt wrote:
> > Today I saw a warning with lyx-2.3.0 as follows:
> > configure: WARNING: unrecognized options: --enable-cxx11
>
> Hi Stephan,
> isn
On Sunday, 25 February 2018 16.58.36 WET Stephan Witt wrote:
> Today I saw a warning with lyx-2.3.0 as follows:
> configure: WARNING: unrecognized options: --enable-cxx11
Hi Stephan,
isn't C++ 11 our basic requirement?
Or said the other way around there is code that do
Am 25.02.2018 um 19:35 schrieb Kornel Benko :
>
> Am Sonntag, 25. Februar 2018 17:58:36 CET schrieb Stephan Witt
> :
>> Hi,
>>
>> usually I’m using the --enable-cxx11 configure option to build LyX binaries
>> on Mac with autotools.
>>
>> To
Am Sonntag, 25. Februar 2018 17:58:36 CET schrieb Stephan Witt
:
> Hi,
>
> usually I’m using the --enable-cxx11 configure option to build LyX binaries
> on Mac with autotools.
>
> Today I saw a warning with lyx-2.3.0 as follows:
> configure: WARNING: unrecognized options:
Hi,
usually I’m using the --enable-cxx11 configure option to build LyX binaries on
Mac with autotools.
Today I saw a warning with lyx-2.3.0 as follows:
configure: WARNING: unrecognized options: --enable-cxx11
So I tried to build w/o this option. But this leads to a configure error:
configure
On Fri, Mar 03, 2017 at 02:02:07PM +0100, Jean-Marc Lasgouttes wrote:
> Le 03/03/2017 à 12:53, Enrico Forestieri a écrit :
> > On Fri, Mar 03, 2017 at 12:06:34PM +0100, Jean-Marc Lasgouttes wrote:
> > > Le 03/03/2017 à 11:52, Enrico Forestieri a écrit :
> > > >
Le 03/03/2017 à 12:53, Enrico Forestieri a écrit :
On Fri, Mar 03, 2017 at 12:06:34PM +0100, Jean-Marc Lasgouttes wrote:
Le 03/03/2017 à 11:52, Enrico Forestieri a écrit :
> configure: error: cannot find suitable MyThes library (do not use
--without-included-mythes)
But I didn&#x
On Thu, Mar 02, 2017 at 02:35:44PM +0100, Jean-Marc Lasgouttes wrote:
> commit 2f701e6a1c6b2a487a28c7a212421aef21f1b58c
> Author: Jean-Marc Lasgouttes
> Date: Thu Mar 2 14:31:43 2017 +0100
>
> Clarify configure help for 3rd party code
>
> The configure c
Le 21/09/2016 à 22:31, Richard Heck a écrit :
commit 076736369f11016e5ed5a0a7dec0a58fc610c608
Author: Richard Heck
Date: Wed Sep 21 16:30:58 2016 -0400
Status and configure for 2.2.3.
---
Hi Richard,
I have rebased 2.2.3-staging branch on top of 2.2.x. You can now safely
delete this
e some "helpful" script in /etc/profile.d that redefines the PATH
variable or defines the qt_cv_bin one? Indeed, I can reproduce your
case by doing
$ env qt_cv_bin=/path/to/qt3/bin configure ...
Note that, before 4bdeae273345, that variable was named qt4_cv_bin.
--
Enrico
Enrico Forestieri wrote:
> > === The following minor problems have been detected by configure.
> > === Please check the messages below before running 'make'.
> > === (see the section 'Problems' in the INSTALL file)
> >
> > == The found moc comp
On Fri, Jan 02, 2015 at 12:29:31PM -0800, Pavel Sanda wrote:
> Hi Enrico,
>
> after 4bdeae273345 configure no more detects correct qt4 libs on my system
That commit didn't change the way the Qt libs are detected, so it should
not be the cause of your problem.
> === The followi
Hi Enrico,
after 4bdeae273345 configure no more detects correct qt4 libs on my system
=== The following minor problems have been detected by configure.
=== Please check the messages below before running 'make'.
=== (see the section 'Problems' in the INSTALL file)
== The f
Am 20.08.2014 um 03:01 schrieb Scott Kostyshak:
I'm CC'ing Uwe and Vincent to see if they have any opinions on bundling Sumatra.
Another user's problem was solved by using Sumatra. I have not heard
back from Vincent or Uwe. I think they are both really busy. Does
anyone else have an opinion on
ample, given the following setting in the SumatraPDF prefs:
>> InverseSearchCmdLine = lyxeditorwin %f %l
>> the batch file would be the following one:
>> $ cat lyxeditorwin.bat
>> @echo off
>> setlocal
>> set file=%1
>> set row=%2
>> echo LYXCMD:revdvi
On Tue, Jul 15, 2014 at 3:41 PM, Enrico Forestieri wrote:
> On Mon, Jul 14, 2014 at 07:08:20PM -0400, Scott Kostyshak wrote:
>> On Sat, May 24, 2014 at 7:40 AM, Scott Kostyshak wrote:
>> > On Sat, May 24, 2014 at 6:56 AM, Enrico Forestieri wrote:
>>
>> >> It would suffice placing the executable
On Mon, Jul 14, 2014 at 07:08:20PM -0400, Scott Kostyshak wrote:
> On Sat, May 24, 2014 at 7:40 AM, Scott Kostyshak wrote:
> > On Sat, May 24, 2014 at 6:56 AM, Enrico Forestieri wrote:
>
> >> It would suffice placing the executable in a directory under the LyX
> >> directory tree that is already
On Sat, May 24, 2014 at 7:40 AM, Scott Kostyshak wrote:
> On Sat, May 24, 2014 at 6:56 AM, Enrico Forestieri wrote:
>> It would suffice placing the executable in a directory under the LyX
>> directory tree that is already in the PATH prefix.
If I understand correctly, it seems like another feat
=%2
> echo LYXCMD:revdvi:server-goto-file-row:%file% %row%> \\.\pipe\lyxpipe.in
> type \\.\pipe\lyxpipe.out > nul
>
> and it would require setting the correct lyxpipe in lyxrc.dist:
> \serverpipe "\\.\pipe\lyxpipe"
Excellent, thank you for the details.
>> Enrico, can you confirm that SumatraPDF is the correct name of the
>> binary to search for in configure?
>
> Yes, it is.
OK then I committed the patch at e716f1ef in the meantime.
I'm CC'ing Uwe and Vincent to see if they have any opinions on bundling Sumatra.
Scott
goto-file-row:%file% %row%> \\.\pipe\lyxpipe.in
type \\.\pipe\lyxpipe.out > nul
and it would require setting the correct lyxpipe in lyxrc.dist:
\serverpipe "\\.\pipe\lyxpipe"
> Enrico, can you confirm that SumatraPDF is the correct name of the
> binary to search for in configure?
Yes, it is.
--
Enrico
and JabRef.
This way, forward/reverse search would work out of the box and we
would have fewer "why does LyX crash when I view a PDF?" questions.
Enrico, can you confirm that SumatraPDF is the correct name of the
binary to search for in configure?
Scott
On Fri, May 23, 2014 at 05:05:42PM -0400, Richard Heck wrote:
> On 05/23/2014 04:36 PM, Scott Kostyshak wrote:
> >I see quite often Windows users experiencing problems with Adobe
> >Reader that are solved by using Sumatra PDF reader, an open source,
> >Windows only PDF reader. One problem that jus
On 05/23/2014 04:36 PM, Scott Kostyshak wrote:
I see quite often Windows users experiencing problems with Adobe
Reader that are solved by using Sumatra PDF reader, an open source,
Windows only PDF reader. One problem that just recently came up is:
http://tex.stackexchange.com/questions/179639/pdf
I see quite often Windows users experiencing problems with Adobe
Reader that are solved by using Sumatra PDF reader, an open source,
Windows only PDF reader. One problem that just recently came up is:
http://tex.stackexchange.com/questions/179639/pdf-crashes-after-previewing-from-lyx
Any thoughts?
Am Donnerstag, 21. November 2013 um 10:28:41, schrieb Pavel Sanda
> Kornel Benko wrote:
> > commit 805e51eff86a1c249d80728dcd3f8d70313bc35e
> > Author: Kornel Benko
> > Date: Wed Nov 20 19:40:32 2013 +0100
> >
> > Implement file locking and apply to con
Kornel Benko wrote:
> commit 805e51eff86a1c249d80728dcd3f8d70313bc35e
> Author: Kornel Benko
> Date: Wed Nov 20 19:40:32 2013 +0100
>
> Implement file locking and apply to configure
>
> Functions for file locking are added. They are used for ensuring tha
-- Forwarded message --
From: stefano franchi
Date: Wed, Nov 13, 2013 at 9:46 AM
Subject: Re: Configure errors on Archlinux for lyx 2.1Beta
To: Kornel Benko
On Wed, Nov 13, 2013 at 9:23 AM, Kornel Benko wrote:
> Am Mittwoch, 13. November 2013 um 09:06:19, schrieb stef
Archlinux, python defaults
> > to
> > > > python3, while the executable for python 2.7 is /usr/bin/python2
> > > >
> > > > Interestingly, configure itself ends successfully. My first attempt at
> > > > compiling (i.e. make) failed immediately wi
It looks like a python2 /python3 issue. On Archlinux, python defaults to
> > python3, while the executable for python 2.7 is /usr/bin/python2
> >
> > Interestingly, configure itself ends successfully. My first attempt at
> > compiling (i.e. make) failed immediately with a d
for python 2.7 is /usr/bin/python2
>
> Interestingly, configure itself ends successfully. My first attempt at
> compiling (i.e. make) failed immediately with a different python-related
> error. I tried again (without reconfiguring) and it worked.
>
> However, I do get the same e
Configuration of the recently released 2.1.beta on my Archlinux system
gives python-related errors (see below).
It looks like a python2 /python3 issue. On Archlinux, python defaults to
python3, while the executable for python 2.7 is /usr/bin/python2
Interestingly, configure itself ends
Le 14/07/13 12:44, Richard Heck a écrit :
Done now. Richard, do you want this in 2.0.x?
If you think it's needed, yes.
Yes, I think it is better. Done now.
JMarc
On 07/13/2013 09:46 AM, Jean-Marc Lasgouttes wrote:
Le 13/07/2013 12:10, Jürgen Spitzmüller a écrit :
Jean-Marc Lasgouttes wrote:
Can I commit this? Where?
Commit it to 2.1-staging.
Done now. Richard, do you want this in 2.0.x?
If you think it's needed, yes.
rh
Le 13/07/2013 12:10, Jürgen Spitzmüller a écrit :
Jean-Marc Lasgouttes wrote:
Can I commit this? Where?
Commit it to 2.1-staging.
Done now. Richard, do you want this in 2.0.x?
JMarc
Jean-Marc Lasgouttes wrote:
> Can I commit this? Where?
Commit it to 2.1-staging.
Jürgen
Le 09/07/2013 17:25, Jean-Marc Lasgouttes a écrit :
07/07/2013 16:27, Stephan Witt:
Hmm… it looks like that:
1. /opt/qt-everywhere-opensource-src-4.8.2/bin has "moc" but not
"moc-qt4"
2. LyX's configure checks for moc-qt4 first and is happy to find it in
/usr/bin
Does
Am 09.07.2013 um 17:25 schrieb Jean-Marc Lasgouttes :
> 07/07/2013 16:27, Stephan Witt:
>> Hmm… it looks like that:
>> 1. /opt/qt-everywhere-opensource-src-4.8.2/bin has "moc" but not "moc-qt4"
>> 2. LyX's configure checks for moc-qt4 first and is
07/07/2013 16:27, Stephan Witt:
Hmm… it looks like that:
1. /opt/qt-everywhere-opensource-src-4.8.2/bin has "moc" but not "moc-qt4"
2. LyX's configure checks for moc-qt4 first and is happy to find it in /usr/bin
Does the following patch make sense? It only searc
07/07/2013 16:27, Stephan Witt:
Hmm… it looks like that:
1. /opt/qt-everywhere-opensource-src-4.8.2/bin has "moc" but not "moc-qt4"
2. LyX's configure checks for moc-qt4 first and is happy to find it in /usr/bin
Are there still systems where looking for qt4-foo makes
Am 07.07.2013 um 15:59 schrieb Georg Ritter :
> On 07/07/13 13:47, Stephan Witt wrote:
>> Am 07.07.2013 um 13:39 schrieb Georg Ritter :
>>
>>> Dear lyx team,
>>>
>>> I just pulled the sources from git an noticed the following:
>>>
>>&g
On 07/07/13 13:47, Stephan Witt wrote:
> Am 07.07.2013 um 13:39 schrieb Georg Ritter :
>
>> Dear lyx team,
>>
>> I just pulled the sources from git an noticed the following:
>>
>> If ./configure --with-qt4-dir=/my/qt4dir482/ is specified, the build
>> s
Am 07.07.2013 um 13:39 schrieb Georg Ritter :
> Dear lyx team,
>
> I just pulled the sources from git an noticed the following:
>
> If ./configure --with-qt4-dir=/my/qt4dir482/ is specified, the build
> system should pickup and use:
> /my/qt4dir/bin/moc
>
> but it
1 - 100 of 943 matches
Mail list logo
