Re: Compilation problem [SOLVED]

[Guido Milanese]

On Tue, 19 Sep 2017 19:13:04 +0200
Jürgen Spitzmüller  wrote:
> From the file INSTALL:
> 
> "Quick compilation guide
> ---
> 
> These four steps will compile, test and install LyX:
> 
>   0) Linux users beware: You need qt4 and qt4-devel packages
>  of the same version to compile LyX."
> 
> BTW you can also compile against qt5 with --enable-qt5
> 
> Jürgen

Thank you -- I did read the file INSTALL, but I wrongly assumed compatibility
with qt5. My fault. I was not aware of the `--enable-qt5` switch, however: I'll
try it next time I install LyX.

Best wishes,
g

---
Guido Milanese, Professor of Classics, PhD HC Paris IC
http://docenti.unicatt.it/ita/guido_fabrizio_milanese/
http://usi.to/tz4

Re: Compilation problem [SOLVED]

[Jürgen Spitzmüller]

Am Dienstag, den 19.09.2017, 19:06 +0200 schrieb Guido Milanese:
> Mystery solved. Lyx does not use the QT5 libraries, it needs QT4
> (with 
> qt4-devel). If I may take the liberty of suggesting a minor
> improvement to the configuration script, I would say that a message
> mentioning the need of the qt4 library would be advisable.

From the file INSTALL:

"Quick compilation guide
---

These four steps will compile, test and install LyX:

0) Linux users beware: You need qt4 and qt4-devel packages
   of the same version to compile LyX."

BTW you can also compile against qt5 with --enable-qt5

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: Compilation problem [SOLVED]

[Guido Milanese]

Mystery solved. Lyx does not use the QT5 libraries, it needs QT4 (with 
qt4-devel). If I may take the liberty of suggesting a minor
improvement to the configuration script, I would say that a message
mentioning the need of the qt4 library would be advisable.

With every best wishes, 
GM

On Tue, 19 Sep 2017 00:03:51 +0200
Guido Milanese  wrote:

> Dear Experts,
> I am trying to compile LyX on my xubuntu 17.04 system (for several
> reasons I do not want to install via apt-get install). I cannot make
> sense of this problem:
> 
> checking for Qt library name... failed
> configure: error: cannot compile a simple Qt executable. Check you
> have the right $QTDIR.
> 
> I tried with 
> export QTDIR=/usr/share/qt5
> 
> but to no success.
> 
> Another problem (may be related?) is 
> 
> checking for ANSI C header files... no
> 
> I have build-essential correctly installed, so I cannot understand
> what I'm missing.
> 
> Thank you!
> guido, italy
> 
> ---
> Guido Milanese, Professor of Classics, PhD HC Paris IC
> http://docenti.unicatt.it/ita/guido_fabrizio_milanese/
> http://usi.to/tz4



---
Guido Milanese, Professor of Classics, PhD HC Paris IC
http://docenti.unicatt.it/ita/guido_fabrizio_milanese/
http://usi.to/tz4

Re: Compilation problem

[stefano franchi]

On Tue, Apr 30, 2013 at 3:30 AM, Emil Pavlov emil.p.pav...@gmail.comwrote:

  На 29.04.2013 23:43, curtis osterhoudt написа:

  I ran into this problem just this weekend (using the 2.1.0 dev version
 of LyX on a debian-based system). I happen to have figured out what I did
 wrong, though it didn't have anything to do with forward/reverse searches;
 I thought the condition was interesting: I put some ERT into my document to
 change some enumeration settings (explicitly, the following command to
 change numbering to a lowercase letter surrounded by parentheses:
 \renewcommand{\theenumi}{(\alph{enumi})}). Later on, though, in playing
 with that command, I changed it to the following:
 \renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of
 circular definition, and pdflatex chokes on it, and LyX appears to be
 frozen (I think it's waiting for pdflatex to finish its compilation).

If you haven't started LyX from the command line (so that you can
 simply ctrl-c it), then you can use the following to kill the process:

  From a command window, run top or htop, and find the process
 (likely gs or pdflatex) which is eating up resources and kill it that way.
 OR
 run the command ps -ef | grep pdflatex (or whatever process you suspect
 of hanging), which will return the process number of the program running.
 Then you can run kill process number (or, for extreme maliciousness,
 kill -9 process number) to make LyX useable again.

Hope that helps!



--
  *From:* Emil Pavlov emil.p.pav...@gmail.com emil.p.pav...@gmail.com
 *To:* lyx-users@lists.lyx.org
 *Sent:* Monday, April 29, 2013 1:15 PM
 *Subject:* Compilation problem

 I have a large lyx document (several child documents, together around 60
 pages) and sometimes I have problems compiling the pdf. I even cannot
 close lyx, because it says it is still compiling.
 1. How can I interrupt the compilation?
 2. How can I fix this?

 I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
 enable forward/reverse search (I really need this feature).

 Best regards,
 Emil



 OK, this happened again. But I cannot find any process called
 pdflatex. This time forward/reverse search was off.



You may not be using pdflatex (there are other backends that produce pdf:
XeLatex. :LuaTeX, Latex with ps2pdf, and so on). When it hangs, try opening
up a terminal and searching for a process containing the tex string in
its name. For example with this command: ps aux | grep tex
Alternatively, you may want to double-check which command you are using to
produce the pdf file from the View menu (you should see it in parentheses
next to the various View pdf items.

It may also be the case that your compilation hangs not on latex but while
processing references (in which case bibtex or biber would be to blame), or
while indexing (texindy, makeindex, xindy).

Stefano
-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic StudiesPh:   +1 (979) 845-2125
Texas AM University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: Compilation problem

[stefano franchi]

On Tue, Apr 30, 2013 at 3:30 AM, Emil Pavlov emil.p.pav...@gmail.comwrote:

  На 29.04.2013 23:43, curtis osterhoudt написа:

  I ran into this problem just this weekend (using the 2.1.0 dev version
 of LyX on a debian-based system). I happen to have figured out what I did
 wrong, though it didn't have anything to do with forward/reverse searches;
 I thought the condition was interesting: I put some ERT into my document to
 change some enumeration settings (explicitly, the following command to
 change numbering to a lowercase letter surrounded by parentheses:
 \renewcommand{\theenumi}{(\alph{enumi})}). Later on, though, in playing
 with that command, I changed it to the following:
 \renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of
 circular definition, and pdflatex chokes on it, and LyX appears to be
 frozen (I think it's waiting for pdflatex to finish its compilation).

If you haven't started LyX from the command line (so that you can
 simply ctrl-c it), then you can use the following to kill the process:

  From a command window, run top or htop, and find the process
 (likely gs or pdflatex) which is eating up resources and kill it that way.
 OR
 run the command ps -ef | grep pdflatex (or whatever process you suspect
 of hanging), which will return the process number of the program running.
 Then you can run kill process number (or, for extreme maliciousness,
 kill -9 process number) to make LyX useable again.

Hope that helps!



--
  *From:* Emil Pavlov emil.p.pav...@gmail.com emil.p.pav...@gmail.com
 *To:* lyx-users@lists.lyx.org
 *Sent:* Monday, April 29, 2013 1:15 PM
 *Subject:* Compilation problem

 I have a large lyx document (several child documents, together around 60
 pages) and sometimes I have problems compiling the pdf. I even cannot
 close lyx, because it says it is still compiling.
 1. How can I interrupt the compilation?
 2. How can I fix this?

 I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
 enable forward/reverse search (I really need this feature).

 Best regards,
 Emil



 OK, this happened again. But I cannot find any process called
 pdflatex. This time forward/reverse search was off.



You may not be using pdflatex (there are other backends that produce pdf:
XeLatex. :LuaTeX, Latex with ps2pdf, and so on). When it hangs, try opening
up a terminal and searching for a process containing the tex string in
its name. For example with this command: ps aux | grep tex
Alternatively, you may want to double-check which command you are using to
produce the pdf file from the View menu (you should see it in parentheses
next to the various View pdf items.

It may also be the case that your compilation hangs not on latex but while
processing references (in which case bibtex or biber would be to blame), or
while indexing (texindy, makeindex, xindy).

Stefano
-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic StudiesPh:   +1 (979) 845-2125
Texas AM University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: Compilation problem

[stefano franchi]

On Tue, Apr 30, 2013 at 3:30 AM, Emil Pavlov wrote:

>  На 29.04.2013 23:43, curtis osterhoudt написа:
>
>  I ran into this problem just this weekend (using the 2.1.0 dev version
> of LyX on a debian-based system). I happen to have figured out what I did
> wrong, though it didn't have anything to do with forward/reverse searches;
> I thought the condition was interesting: I put some ERT into my document to
> change some enumeration settings (explicitly, the following command to
> change numbering to a lowercase letter surrounded by parentheses:
> \renewcommand{\theenumi}{(\alph{enumi})}). Later on, though, in playing
> with that command, I changed it to the following:
> \renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of
> circular definition, and pdflatex chokes on it, and LyX appears to be
> frozen (I think it's waiting for pdflatex to finish its compilation).
>
>If you haven't started LyX from the command line (so that you can
> simply ctrl-c it), then you can use the following to kill the process:
>
>  >From a command window, run "top" or "htop", and find the process
> (likely gs or pdflatex) which is eating up resources and kill it that way.
> OR
> run the command "ps -ef | grep pdflatex" (or whatever process you suspect
> of hanging), which will return the process number of the program running.
> Then you can run "kill " (or, for extreme maliciousness,
> "kill -9 ") to make LyX useable again.
>
>Hope that helps!
>
>
>
>--
>  *From:* Emil Pavlov  
> *To:* lyx-users@lists.lyx.org
> *Sent:* Monday, April 29, 2013 1:15 PM
> *Subject:* Compilation problem
>
> I have a large lyx document (several child documents, together around 60
> pages) and sometimes I have problems compiling the pdf. I even cannot
> close lyx, because it says it is still compiling.
> 1. How can I interrupt the compilation?
> 2. How can I fix this?
>
> I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
> enable forward/reverse search (I really need this feature).
>
> Best regards,
> Emil
>
>
>
> OK, this happened again. But I cannot find any process called
> pdflatex. This time forward/reverse search was off.
>


You may not be using pdflatex (there are other backends that produce pdf:
XeLatex. :LuaTeX, Latex with ps2pdf, and so on). When it hangs, try opening
up a terminal and searching for a process containing the "tex" string in
its name. For example with this command: ps aux | grep tex
Alternatively, you may want to double-check which command you are using to
produce the pdf file from the View menu (you should see it in parentheses
next to the various "View pdf" items.

It may also be the case that your compilation hangs not on latex but while
processing references (in which case bibtex or biber would be to blame), or
while indexing (texindy, makeindex, xindy).

Stefano
-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic StudiesPh:   +1 (979) 845-2125
Texas A University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: Compilation problem

[Emil Pavlov]

?? 29.04.2013 23:43, curtis osterhoudt ??:
I ran into this problem just this weekend (using the 2.1.0 dev version 
of LyX on a debian-based system). I happen to have figured out what I 
did wrong, though it didn't have anything to do with forward/reverse 
searches; I thought the condition was interesting: I put some ERT into 
my document to change some enumeration settings (explicitly, the 
following command to change numbering to a lowercase letter surrounded 
by parentheses: \renewcommand{\theenumi}{(\alph{enumi})}). Later on, 
though, in playing with that command, I changed it to the following: 
\renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of 
circular definition, and pdflatex chokes on it, and LyX appears to be 
frozen (I think it's waiting for pdflatex to finish its compilation).


  If you haven't started LyX from the command line (so that you can 
simply ctrl-c it), then you can use the following to kill the process:


From a command window, run top or htop, and find the process (likely gs or pdflatex) which is eating up resources 
and kill it that way.

OR
run the command ps -ef | grep pdflatex (or whatever process you 
suspect of hanging), which will return the process number of the 
program running. Then you can run kill process number (or, for 
extreme maliciousness, kill -9 process number) to make LyX useable 
again.


  Hope that helps!




*From:* Emil Pavlov emil.p.pav...@gmail.com
*To:* lyx-users@lists.lyx.org
*Sent:* Monday, April 29, 2013 1:15 PM
*Subject:* Compilation problem

I have a large lyx document (several child documents, together
around 60
pages) and sometimes I have problems compiling the pdf. I even cannot
close lyx, because it says it is still compiling.
1. How can I interrupt the compilation?
2. How can I fix this?

I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
enable forward/reverse search (I really need this feature).

Best regards,
Emil




Well, it helps a bit, but I still don't know why pdflatex hangs.

Re: Compilation problem

[Emil Pavlov]

?? 29.04.2013 23:43, curtis osterhoudt ??:
I ran into this problem just this weekend (using the 2.1.0 dev version 
of LyX on a debian-based system). I happen to have figured out what I 
did wrong, though it didn't have anything to do with forward/reverse 
searches; I thought the condition was interesting: I put some ERT into 
my document to change some enumeration settings (explicitly, the 
following command to change numbering to a lowercase letter surrounded 
by parentheses: \renewcommand{\theenumi}{(\alph{enumi})}). Later on, 
though, in playing with that command, I changed it to the following: 
\renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of 
circular definition, and pdflatex chokes on it, and LyX appears to be 
frozen (I think it's waiting for pdflatex to finish its compilation).


  If you haven't started LyX from the command line (so that you can 
simply ctrl-c it), then you can use the following to kill the process:


From a command window, run top or htop, and find the process (likely gs or pdflatex) which is eating up resources 
and kill it that way.

OR
run the command ps -ef | grep pdflatex (or whatever process you 
suspect of hanging), which will return the process number of the 
program running. Then you can run kill process number (or, for 
extreme maliciousness, kill -9 process number) to make LyX useable 
again.


  Hope that helps!




*From:* Emil Pavlov emil.p.pav...@gmail.com
*To:* lyx-users@lists.lyx.org
*Sent:* Monday, April 29, 2013 1:15 PM
*Subject:* Compilation problem

I have a large lyx document (several child documents, together
around 60
pages) and sometimes I have problems compiling the pdf. I even cannot
close lyx, because it says it is still compiling.
1. How can I interrupt the compilation?
2. How can I fix this?

I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
enable forward/reverse search (I really need this feature).

Best regards,
Emil



OK, this happened again. But I cannot find any process called pdflatex. 
This time forward/reverse search was off.

Re: Compilation problem

[Emil Pavlov]

?? 29.04.2013 23:43, curtis osterhoudt ??:
I ran into this problem just this weekend (using the 2.1.0 dev version 
of LyX on a debian-based system). I happen to have figured out what I 
did wrong, though it didn't have anything to do with forward/reverse 
searches; I thought the condition was interesting: I put some ERT into 
my document to change some enumeration settings (explicitly, the 
following command to change numbering to a lowercase letter surrounded 
by parentheses: \renewcommand{\theenumi}{(\alph{enumi})}). Later on, 
though, in playing with that command, I changed it to the following: 
\renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of 
circular definition, and pdflatex chokes on it, and LyX appears to be 
frozen (I think it's waiting for pdflatex to finish its compilation).


  If you haven't started LyX from the command line (so that you can 
simply ctrl-c it), then you can use the following to kill the process:


From a command window, run top or htop, and find the process (likely gs or pdflatex) which is eating up resources 
and kill it that way.

OR
run the command ps -ef | grep pdflatex (or whatever process you 
suspect of hanging), which will return the process number of the 
program running. Then you can run kill process number (or, for 
extreme maliciousness, kill -9 process number) to make LyX useable 
again.


  Hope that helps!




*From:* Emil Pavlov emil.p.pav...@gmail.com
*To:* lyx-users@lists.lyx.org
*Sent:* Monday, April 29, 2013 1:15 PM
*Subject:* Compilation problem

I have a large lyx document (several child documents, together
around 60
pages) and sometimes I have problems compiling the pdf. I even cannot
close lyx, because it says it is still compiling.
1. How can I interrupt the compilation?
2. How can I fix this?

I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
enable forward/reverse search (I really need this feature).

Best regards,
Emil




Well, it helps a bit, but I still don't know why pdflatex hangs.

Re: Compilation problem

[Emil Pavlov]

?? 29.04.2013 23:43, curtis osterhoudt ??:
I ran into this problem just this weekend (using the 2.1.0 dev version 
of LyX on a debian-based system). I happen to have figured out what I 
did wrong, though it didn't have anything to do with forward/reverse 
searches; I thought the condition was interesting: I put some ERT into 
my document to change some enumeration settings (explicitly, the 
following command to change numbering to a lowercase letter surrounded 
by parentheses: \renewcommand{\theenumi}{(\alph{enumi})}). Later on, 
though, in playing with that command, I changed it to the following: 
\renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of 
circular definition, and pdflatex chokes on it, and LyX appears to be 
frozen (I think it's waiting for pdflatex to finish its compilation).


  If you haven't started LyX from the command line (so that you can 
simply ctrl-c it), then you can use the following to kill the process:


From a command window, run top or htop, and find the process (likely gs or pdflatex) which is eating up resources 
and kill it that way.

OR
run the command ps -ef | grep pdflatex (or whatever process you 
suspect of hanging), which will return the process number of the 
program running. Then you can run kill process number (or, for 
extreme maliciousness, kill -9 process number) to make LyX useable 
again.


  Hope that helps!




*From:* Emil Pavlov emil.p.pav...@gmail.com
*To:* lyx-users@lists.lyx.org
*Sent:* Monday, April 29, 2013 1:15 PM
*Subject:* Compilation problem

I have a large lyx document (several child documents, together
around 60
pages) and sometimes I have problems compiling the pdf. I even cannot
close lyx, because it says it is still compiling.
1. How can I interrupt the compilation?
2. How can I fix this?

I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
enable forward/reverse search (I really need this feature).

Best regards,
Emil



OK, this happened again. But I cannot find any process called pdflatex. 
This time forward/reverse search was off.

Re: Compilation problem

[Emil Pavlov]

?? 29.04.2013 23:43, curtis osterhoudt ??:
I ran into this problem just this weekend (using the 2.1.0 dev version 
of LyX on a debian-based system). I happen to have figured out what I 
did wrong, though it didn't have anything to do with forward/reverse 
searches; I thought the condition was interesting: I put some ERT into 
my document to change some enumeration settings (explicitly, the 
following command to change numbering to a lowercase letter surrounded 
by parentheses: \renewcommand{\theenumi}{(\alph{enumi})}). Later on, 
though, in playing with that command, I changed it to the following: 
\renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of 
circular definition, and pdflatex chokes on it, and LyX appears to be 
frozen (I think it's waiting for pdflatex to finish its compilation).


  If you haven't started LyX from the command line (so that you can 
simply ctrl-c it), then you can use the following to kill the process:


>From a command window, run "top" or "htop", and find the process (likely gs or pdflatex) which is eating up resources 
and kill it that way.

OR
run the command "ps -ef | grep pdflatex" (or whatever process you 
suspect of hanging), which will return the process number of the 
program running. Then you can run "kill " (or, for 
extreme maliciousness, "kill -9 ") to make LyX useable 
again.


  Hope that helps!




*From:* Emil Pavlov 
*To:* lyx-users@lists.lyx.org
*Sent:* Monday, April 29, 2013 1:15 PM
*Subject:* Compilation problem

I have a large lyx document (several child documents, together
around 60
pages) and sometimes I have problems compiling the pdf. I even cannot
close lyx, because it says it is still compiling.
1. How can I interrupt the compilation?
2. How can I fix this?

I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
enable forward/reverse search (I really need this feature).

Best regards,
Emil




Well, it helps a bit, but I still don't know why pdflatex hangs.

Re: Compilation problem

[Emil Pavlov]

?? 29.04.2013 23:43, curtis osterhoudt ??:
I ran into this problem just this weekend (using the 2.1.0 dev version 
of LyX on a debian-based system). I happen to have figured out what I 
did wrong, though it didn't have anything to do with forward/reverse 
searches; I thought the condition was interesting: I put some ERT into 
my document to change some enumeration settings (explicitly, the 
following command to change numbering to a lowercase letter surrounded 
by parentheses: \renewcommand{\theenumi}{(\alph{enumi})}). Later on, 
though, in playing with that command, I changed it to the following: 
\renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of 
circular definition, and pdflatex chokes on it, and LyX appears to be 
frozen (I think it's waiting for pdflatex to finish its compilation).


  If you haven't started LyX from the command line (so that you can 
simply ctrl-c it), then you can use the following to kill the process:


>From a command window, run "top" or "htop", and find the process (likely gs or pdflatex) which is eating up resources 
and kill it that way.

OR
run the command "ps -ef | grep pdflatex" (or whatever process you 
suspect of hanging), which will return the process number of the 
program running. Then you can run "kill " (or, for 
extreme maliciousness, "kill -9 ") to make LyX useable 
again.


  Hope that helps!




*From:* Emil Pavlov 
*To:* lyx-users@lists.lyx.org
*Sent:* Monday, April 29, 2013 1:15 PM
*Subject:* Compilation problem

I have a large lyx document (several child documents, together
around 60
pages) and sometimes I have problems compiling the pdf. I even cannot
close lyx, because it says it is still compiling.
1. How can I interrupt the compilation?
2. How can I fix this?

I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
enable forward/reverse search (I really need this feature).

Best regards,
Emil



OK, this happened again. But I cannot find any process called pdflatex. 
This time forward/reverse search was off.

Re: Compilation problem

[curtis osterhoudt]

I ran into this problem just this weekend (using the 2.1.0 dev version of LyX 
on a debian-based system). I happen to have figured out what I did wrong, 
though it didn't have anything to do with forward/reverse searches; I thought 
the condition was interesting: I put some ERT into my document to change some 
enumeration settings (explicitly, the following command to change numbering to 
a lowercase letter surrounded by parentheses: 
\renewcommand{\theenumi}{(\alph{enumi})}). Later on, though, in playing with 
that command, I changed it to the following: 
\renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of circular 
definition, and pdflatex chokes on it, and LyX appears to be frozen (I think 
it's waiting for pdflatex to finish its compilation). 

  If you haven't started LyX from the command line (so that you can simply 
ctrl-c it), then you can use the following to kill the process:

From a command window, run top or htop, and find the process (likely gs or 
pdflatex) which is eating up resources and kill it that way.
OR
run the command ps -ef | grep pdflatex (or whatever process you suspect of 
hanging), which will return the process number of the program running. Then you 
can run kill process number (or, for extreme maliciousness, kill -9 
process number) to make LyX useable again. 

  Hope that helps!





 From: Emil Pavlov emil.p.pav...@gmail.com
To: lyx-users@lists.lyx.org 
Sent: Monday, April 29, 2013 1:15 PM
Subject: Compilation problem
 

I have a large lyx document (several child documents, together around 60
pages) and sometimes I have problems compiling the pdf. I even cannot
close lyx, because it says it is still compiling.
1. How can I interrupt the compilation?
2. How can I fix this?

I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
enable forward/reverse search (I really need this feature).

Best regards,
Emil

Re: Compilation problem

[curtis osterhoudt]

I ran into this problem just this weekend (using the 2.1.0 dev version of LyX 
on a debian-based system). I happen to have figured out what I did wrong, 
though it didn't have anything to do with forward/reverse searches; I thought 
the condition was interesting: I put some ERT into my document to change some 
enumeration settings (explicitly, the following command to change numbering to 
a lowercase letter surrounded by parentheses: 
\renewcommand{\theenumi}{(\alph{enumi})}). Later on, though, in playing with 
that command, I changed it to the following: 
\renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of circular 
definition, and pdflatex chokes on it, and LyX appears to be frozen (I think 
it's waiting for pdflatex to finish its compilation). 

  If you haven't started LyX from the command line (so that you can simply 
ctrl-c it), then you can use the following to kill the process:

From a command window, run top or htop, and find the process (likely gs or 
pdflatex) which is eating up resources and kill it that way.
OR
run the command ps -ef | grep pdflatex (or whatever process you suspect of 
hanging), which will return the process number of the program running. Then you 
can run kill process number (or, for extreme maliciousness, kill -9 
process number) to make LyX useable again. 

  Hope that helps!





 From: Emil Pavlov emil.p.pav...@gmail.com
To: lyx-users@lists.lyx.org 
Sent: Monday, April 29, 2013 1:15 PM
Subject: Compilation problem
 

I have a large lyx document (several child documents, together around 60
pages) and sometimes I have problems compiling the pdf. I even cannot
close lyx, because it says it is still compiling.
1. How can I interrupt the compilation?
2. How can I fix this?

I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
enable forward/reverse search (I really need this feature).

Best regards,
Emil

Re: Compilation problem

[curtis osterhoudt]

I ran into this problem just this weekend (using the 2.1.0 dev version of LyX 
on a debian-based system). I happen to have figured out what I did wrong, 
though it didn't have anything to do with forward/reverse searches; I thought 
the condition was interesting: I put some ERT into my document to change some 
enumeration settings (explicitly, the following command to change numbering to 
a lowercase letter surrounded by parentheses: 
\renewcommand{\theenumi}{(\alph{enumi})}). Later on, though, in playing with 
that command, I changed it to the following: 
\renewcommand{\theenumi}{(\theenumi)}. This, I think, is a sort of circular 
definition, and pdflatex chokes on it, and LyX appears to be frozen (I think 
it's waiting for pdflatex to finish its compilation). 

  If you haven't started LyX from the command line (so that you can simply 
ctrl-c it), then you can use the following to kill the process:

From a command window, run "top" or "htop", and find the process (likely gs or 
pdflatex) which is eating up resources and kill it that way.
OR
run the command "ps -ef | grep pdflatex" (or whatever process you suspect of 
hanging), which will return the process number of the program running. Then you 
can run "kill " (or, for extreme maliciousness, "kill -9 
") to make LyX useable again. 

  Hope that helps!




>
> From: Emil Pavlov 
>To: lyx-users@lists.lyx.org 
>Sent: Monday, April 29, 2013 1:15 PM
>Subject: Compilation problem
> 
>
>I have a large lyx document (several child documents, together around 60
>pages) and sometimes I have problems compiling the pdf. I even cannot
>close lyx, because it says it is still compiling.
>1. How can I interrupt the compilation?
>2. How can I fix this?
>
>I have Lyx 2.0.5.1 on Linux mint 13. The problem usually occurs when I
>enable forward/reverse search (I really need this feature).
>
>Best regards,
>Emil
>
>
>
>

Re: Compilation problem

[Emil Pavlov]

На 26.04.2012 16:09, Richard Heck написа:


I had to take out the figures to get it to work, since I don't have 
those, but then it complied fine for me. I guess I'd suggest 
continuing to bisect it. Alternatively, export to LaTeX and compile 
manually. That may give more information.


rh

On 04/26/2012 10:04 AM, Emil Pavlov wrote:

На 26.04.2012 14:07, Richard Heck написа:

On 04/25/2012 06:44 PM, Emil Pavlov wrote:
I have a problem with compiling my bachelor thesis and do not know 
what to do. Can you take a look and give me some ideas?


Erase the last half of it, and see if it compiles. If so, put that 
back and erase the first half. Keep going until you isolate the 
problem.


Obviously, do this on a copy, not on the original!

Richard


Ok, I have located the problem just to one section, but I still 
cannot figure out what is wrong.


Here is the error log and the file is the attachment:

! Missing { inserted.

to be read again

}

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.

to be read again

\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.

to be read again

\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.

to be read again

\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.

to be read again

\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.


Emil




Well, I removed all the figures but I still have the problem. Exporting 
to latex didn't help either.


Emil

Re: Compilation problem

[Emil Pavlov]

На 26.04.2012 16:09, Richard Heck написа:


I had to take out the figures to get it to work, since I don't have 
those, but then it complied fine for me. I guess I'd suggest 
continuing to bisect it. Alternatively, export to LaTeX and compile 
manually. That may give more information.


rh

On 04/26/2012 10:04 AM, Emil Pavlov wrote:

На 26.04.2012 14:07, Richard Heck написа:

On 04/25/2012 06:44 PM, Emil Pavlov wrote:
I have a problem with compiling my bachelor thesis and do not know 
what to do. Can you take a look and give me some ideas?


Erase the last half of it, and see if it compiles. If so, put that 
back and erase the first half. Keep going until you isolate the 
problem.


Obviously, do this on a copy, not on the original!

Richard


Ok, I have located the problem just to one section, but I still 
cannot figure out what is wrong.


Here is the error log and the file is the attachment:

! Missing { inserted.

to be read again

}

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.

to be read again

\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.

to be read again

\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.

to be read again

\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.

to be read again

\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.

inserted text

}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the inserted text above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.


Emil




Well, I removed all the figures but I still have the problem. Exporting 
to latex didn't help either.


Emil

Re: Compilation problem

[Emil Pavlov]

На 26.04.2012 16:09, Richard Heck написа:


I had to take out the figures to get it to work, since I don't have 
those, but then it complied fine for me. I guess I'd suggest 
continuing to bisect it. Alternatively, export to LaTeX and compile 
manually. That may give more information.


rh

On 04/26/2012 10:04 AM, Emil Pavlov wrote:

На 26.04.2012 14:07, Richard Heck написа:

On 04/25/2012 06:44 PM, Emil Pavlov wrote:
I have a problem with compiling my bachelor thesis and do not know 
what to do. Can you take a look and give me some ideas?


Erase the last half of it, and see if it compiles. If so, put that 
back and erase the first half. Keep going until you isolate the 
problem.


Obviously, do this on a copy, not on the original!

Richard


Ok, I have located the problem just to one section, but I still 
cannot figure out what is wrong.


Here is the error log and the file is the attachment:

! Missing { inserted.



}

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.



}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the  above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.



\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.



}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the  above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.



\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.



}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the  above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.



\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.



}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the  above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.

! Missing { inserted.



\egroup

l.193 \end{document}

A left brace was mandatory here, so I've put one in.

You might want to delete and/or insert some corrections

so that I will find a matching right brace soon.

(If you're confused by all this, try typing `I}' now.)

! Missing } inserted.



}

l.193 \end{document}

I've inserted something that you may have forgotten.

(See the  above.)

With luck, this will get me unwedged. But if you

really didn't forget anything, try typing `2' now; then

my insertion and my current dilemma will both disappear.


Emil




Well, I removed all the figures but I still have the problem. Exporting 
to latex didn't help either.


Emil

Re: Compilation problem

[Richard Heck]

On 04/25/2012 06:44 PM, Emil Pavlov wrote:
I have a problem with compiling my bachelor thesis and do not know 
what to do. Can you take a look and give me some ideas?


Erase the last half of it, and see if it compiles. If so, put that back 
and erase the first half. Keep going until you isolate the problem.


Obviously, do this on a copy, not on the original!

Richard

Re: Compilation problem

[Richard Heck]

On 04/25/2012 06:44 PM, Emil Pavlov wrote:
I have a problem with compiling my bachelor thesis and do not know 
what to do. Can you take a look and give me some ideas?


Erase the last half of it, and see if it compiles. If so, put that back 
and erase the first half. Keep going until you isolate the problem.


Obviously, do this on a copy, not on the original!

Richard

Re: Compilation problem

[Richard Heck]

On 04/25/2012 06:44 PM, Emil Pavlov wrote:
I have a problem with compiling my bachelor thesis and do not know 
what to do. Can you take a look and give me some ideas?


Erase the last half of it, and see if it compiles. If so, put that back 
and erase the first half. Keep going until you isolate the problem.


Obviously, do this on a copy, not on the original!

Richard

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Lars Gullik Bjønnes]

Alfredo Braunstein [EMAIL PROTECTED] writes:

| On an ideal world, I don't see the point of the lyx:: namespace.

except when used to protect against our own pollution of the global
namespace.

-- 
Lgb

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Lars Gullik Bjønnes]

Alfredo Braunstein [EMAIL PROTECTED] writes:

| On an ideal world, I don't see the point of the lyx:: namespace.

except when used to protect against our own pollution of the global
namespace.

-- 
Lgb

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Lars Gullik Bjønnes]

Alfredo Braunstein <[EMAIL PROTECTED]> writes:

| On an ideal world, I don't see the point of the lyx:: namespace.

except when used to protect against our own pollution of the global
namespace.

-- 
Lgb

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Andre Poenitz]

On Tue, Jul 01, 2003 at 11:01:30PM +0100, John Levon wrote:
   `class ControlRef'
  
  As far as I understand it, this is a naming clash. Qt has a 
  typedef struct OpaqueControlRef *ControlRef;
 
 Has anyone reported this stupid bug to Troll Tech yet ?

They are as guilty as we are.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Alfredo Braunstein]

Andre Poenitz wrote:

 Has anyone reported this stupid bug to Troll Tech yet ?
 
 They are as guilty as we are.

Why? Lyx is not a library. IMHO a library is responsible of not polluting
the global namespace (and qt way of doing that, btw, seems to be adding a
'q' on front of _almost_ every defined object).
Not to mention the 'signals' macro defined on qt headers.

On an ideal world, I don't see the point of the lyx:: namespace.

Regards, Alfredo

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Andre Poenitz]

On Tue, Jul 01, 2003 at 11:01:30PM +0100, John Levon wrote:
   `class ControlRef'
  
  As far as I understand it, this is a naming clash. Qt has a 
  typedef struct OpaqueControlRef *ControlRef;
 
 Has anyone reported this stupid bug to Troll Tech yet ?

They are as guilty as we are.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Alfredo Braunstein]

Andre Poenitz wrote:

 Has anyone reported this stupid bug to Troll Tech yet ?
 
 They are as guilty as we are.

Why? Lyx is not a library. IMHO a library is responsible of not polluting
the global namespace (and qt way of doing that, btw, seems to be adding a
'q' on front of _almost_ every defined object).
Not to mention the 'signals' macro defined on qt headers.

On an ideal world, I don't see the point of the lyx:: namespace.

Regards, Alfredo

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Andre Poenitz]

On Tue, Jul 01, 2003 at 11:01:30PM +0100, John Levon wrote:
> > > `class ControlRef'
> > 
> > As far as I understand it, this is a naming clash. Qt has a 
> > typedef struct OpaqueControlRef *ControlRef;
> 
> Has anyone reported this stupid bug to Troll Tech yet ?

They are as guilty as we are.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Alfredo Braunstein]

Andre Poenitz wrote:

>> Has anyone reported this stupid bug to Troll Tech yet ?
> 
> They are as guilty as we are.

Why? Lyx is not a library. IMHO a library is responsible of not polluting
the global namespace (and qt way of doing that, btw, seems to be adding a
'q' on front of _almost_ every defined object).
Not to mention the 'signals' macro defined on qt headers.

On an ideal world, I don't see the point of the lyx:: namespace.

Regards, Alfredo

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[John Levon]

On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:

  /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
  types for `typedef struct OpaqueControlRef * ControlRef'
  ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
  `class ControlRef'
 
 As far as I understand it, this is a naming clash. Qt has a 
 typedef struct OpaqueControlRef *ControlRef;

Has anyone reported this stupid bug to Troll Tech yet ?

regards
john

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Ronald Florence]

John Levon [EMAIL PROTECTED] writes:

 On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
 
   /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
   types for `typedef struct OpaqueControlRef * ControlRef'
   ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
   `class ControlRef'
  
  As far as I understand it, this is a naming clash. Qt has a 
  typedef struct OpaqueControlRef *ControlRef;
 
 Has anyone reported this stupid bug to Troll Tech yet ?

The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
-- 

Ronald Florence www.18james.com

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Jan Peters]

/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: 
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous 
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef struct OpaqueControlRef *ControlRef;
Has anyone reported this stupid bug to Troll Tech yet ?
The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
I do not agree upon the statement that Trolltech is not interested in 
supporting
and  bug reports on QT/Aqua ! In fact, I think the opposite is the 
case: they want
open source programmers to report their bugs so that they can finally
solve most of them - thats why they released QT/Aqua under GPL in the 
first
place!

I suggest we send them every bug we find! And: whenever I asked them for
help, they responded so far!
Jan

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[John Levon]

On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:

  /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
  types for `typedef struct OpaqueControlRef * ControlRef'
  ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
  `class ControlRef'
 
 As far as I understand it, this is a naming clash. Qt has a 
 typedef struct OpaqueControlRef *ControlRef;

Has anyone reported this stupid bug to Troll Tech yet ?

regards
john

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Ronald Florence]

John Levon [EMAIL PROTECTED] writes:

 On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
 
   /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
   types for `typedef struct OpaqueControlRef * ControlRef'
   ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
   `class ControlRef'
  
  As far as I understand it, this is a naming clash. Qt has a 
  typedef struct OpaqueControlRef *ControlRef;
 
 Has anyone reported this stupid bug to Troll Tech yet ?

The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
-- 

Ronald Florence www.18james.com

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Jan Peters]

/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: 
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous 
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef struct OpaqueControlRef *ControlRef;
Has anyone reported this stupid bug to Troll Tech yet ?
The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
I do not agree upon the statement that Trolltech is not interested in 
supporting
and  bug reports on QT/Aqua ! In fact, I think the opposite is the 
case: they want
open source programmers to report their bugs so that they can finally
solve most of them - thats why they released QT/Aqua under GPL in the 
first
place!

I suggest we send them every bug we find! And: whenever I asked them for
help, they responded so far!
Jan

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[John Levon]

On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:

> > /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
> > types for `typedef struct OpaqueControlRef * ControlRef'
> > ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
> > `class ControlRef'
> 
> As far as I understand it, this is a naming clash. Qt has a 
> typedef struct OpaqueControlRef *ControlRef;

Has anyone reported this stupid bug to Troll Tech yet ?

regards
john

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Ronald Florence]

John Levon <[EMAIL PROTECTED]> writes:

> On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
> 
> > > /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
> > > types for `typedef struct OpaqueControlRef * ControlRef'
> > > ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
> > > `class ControlRef'
> > 
> > As far as I understand it, this is a naming clash. Qt has a 
> > typedef struct OpaqueControlRef *ControlRef;
> 
> Has anyone reported this stupid bug to Troll Tech yet ?

The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
-- 

Ronald Florence www.18james.com

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Jan Peters]

/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: 
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous 
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef struct OpaqueControlRef *ControlRef;
Has anyone reported this stupid bug to Troll Tech yet ?
The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
I do not agree upon the statement that Trolltech is not interested in 
supporting
and  bug reports on QT/Aqua ! In fact, I think the opposite is the 
case: they want
open source programmers to report their bugs so that they can finally
solve most of them - thats why they released QT/Aqua under GPL in the 
first
place!

I suggest we send them every bug we find! And: whenever I asked them for
help, they responded so far!
Jan

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-25, 18:03 GMT, Matej Cepl wrote:
 On 2003-06-25, 08:27 GMT, Jean-Marc Lasgouttes wrote:
 You need at least automake 1.5 to compile LyX for Qt (this does not
 apply if you did not run autogen.sh, of course).
 
 OK, I did everything seems to be OK up to this point (John? It is
 probably your patch, isn't it?):

I temporarily gave up on the John's patch, so I am going to
compile just plain LyX with Qt. When running ./autogen.sh (with
automake 1.5) it gives me these warnings:

   configure.ac:6: warning: do not use m4_patsubst: use patsubst \
  or m4_bpatsubst
   configure.ac:389: warning: do not use m4_regexp: use regexp \
  or m4_bregexp

Is it something I (or developers) should be concerned about?

I will report, whether I have succeeded.

   Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Compilation problem with Debian

[Thomas Templin]

On Wednesday 25 June 2003 04:54, Matej Cepl wrote:
 Trying to compile lyx with Qt with Qt3 (patched with ct.1.3-diff
 patch). Configure goes without problems, but compilation aborts
 with this (no error in previous compilations):
[...]
You may find a lyx-qt and a lyx-xforms Debian Package at:
deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib \ 
non-free

Perhaps this will comply your needs 

Bye,
Thomas

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-28, 14:36 GMT, Thomas Templin wrote:
 On Wednesday 25 June 2003 04:54, Matej Cepl wrote:
 Trying to compile lyx with Qt with Qt3 (patched with ct.1.3-diff
 patch). Configure goes without problems, but compilation aborts
 with this (no error in previous compilations):
 [...]
 You may find a lyx-qt and a lyx-xforms Debian Package at:
 deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib \ 
 non-free

Unfortunately, I have installed KDE 3.1.2 here and it somehow breaks AA
in lyx-qt build for KDE 2.2.*.

   Thanks for the offer though,

  Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Compilation problem with Debian

[Thomas Templin]

On Saturday 28 June 2003 17:32, Matej Cepl wrote:
 On 2003-06-28, 14:36 GMT, Thomas Templin wrote:
  On Wednesday 25 June 2003 04:54, Matej Cepl wrote:
  Trying to compile lyx with Qt with Qt3 (patched with
  ct.1.3-diff patch). Configure goes without problems, but
  compilation aborts with this (no error in previous
  compilations):
 
  [...]
  You may find a lyx-qt and a lyx-xforms Debian Package at:
  deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main
  contrib \ non-free

 Unfortunately, I have installed KDE 3.1.2 here and it somehow
 breaks AA in lyx-qt build for KDE 2.2.*.
That deb's are for KDE 3.1.2, Im using them with KDE 3.1.2 stable 
and unstable for quite a while, no problems yet.
IMO Adrian Bunk has made one of the best Bakport Sites I knew, 
always good for fishing interesting Backport Packages.
Which KDE 3.1.2 do you use better which installation source? 

deb http://download.kde.org/stable/3.1.2/Debian stable main

deb ftp://ftp.de.debian.org/debian  unstable main non-free contrib

deb http://wh9.tu-dresden.de/kde3/karolina ./ 
It may cause problems using Karolina's KDE Packages, so did I ;o)

Bye,
Thomas

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-28, 15:52 GMT, Thomas Templin wrote:
 Which KDE 3.1.2 do you use better which installation source? 
 
 deb http://download.kde.org/stable/3.1.2/Debian stable main

This one.

 deb ftp://ftp.de.debian.org/debian  unstable main non-free contrib
 
 deb http://wh9.tu-dresden.de/kde3/karolina ./ 
 It may cause problems using Karolina's KDE Packages, so did I ;o)

I am now compiling QContentPane, so I will probably leave it there, but
I may try your site later. Thanks for providing it!

Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-25, 18:03 GMT, Matej Cepl wrote:
 On 2003-06-25, 08:27 GMT, Jean-Marc Lasgouttes wrote:
 You need at least automake 1.5 to compile LyX for Qt (this does not
 apply if you did not run autogen.sh, of course).
 
 OK, I did everything seems to be OK up to this point (John? It is
 probably your patch, isn't it?):

I temporarily gave up on the John's patch, so I am going to
compile just plain LyX with Qt. When running ./autogen.sh (with
automake 1.5) it gives me these warnings:

   configure.ac:6: warning: do not use m4_patsubst: use patsubst \
  or m4_bpatsubst
   configure.ac:389: warning: do not use m4_regexp: use regexp \
  or m4_bregexp

Is it something I (or developers) should be concerned about?

I will report, whether I have succeeded.

   Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Compilation problem with Debian

[Thomas Templin]

On Wednesday 25 June 2003 04:54, Matej Cepl wrote:
 Trying to compile lyx with Qt with Qt3 (patched with ct.1.3-diff
 patch). Configure goes without problems, but compilation aborts
 with this (no error in previous compilations):
[...]
You may find a lyx-qt and a lyx-xforms Debian Package at:
deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib \ 
non-free

Perhaps this will comply your needs 

Bye,
Thomas

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-28, 14:36 GMT, Thomas Templin wrote:
 On Wednesday 25 June 2003 04:54, Matej Cepl wrote:
 Trying to compile lyx with Qt with Qt3 (patched with ct.1.3-diff
 patch). Configure goes without problems, but compilation aborts
 with this (no error in previous compilations):
 [...]
 You may find a lyx-qt and a lyx-xforms Debian Package at:
 deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib \ 
 non-free

Unfortunately, I have installed KDE 3.1.2 here and it somehow breaks AA
in lyx-qt build for KDE 2.2.*.

   Thanks for the offer though,

  Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Compilation problem with Debian

[Thomas Templin]

On Saturday 28 June 2003 17:32, Matej Cepl wrote:
 On 2003-06-28, 14:36 GMT, Thomas Templin wrote:
  On Wednesday 25 June 2003 04:54, Matej Cepl wrote:
  Trying to compile lyx with Qt with Qt3 (patched with
  ct.1.3-diff patch). Configure goes without problems, but
  compilation aborts with this (no error in previous
  compilations):
 
  [...]
  You may find a lyx-qt and a lyx-xforms Debian Package at:
  deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main
  contrib \ non-free

 Unfortunately, I have installed KDE 3.1.2 here and it somehow
 breaks AA in lyx-qt build for KDE 2.2.*.
That deb's are for KDE 3.1.2, Im using them with KDE 3.1.2 stable 
and unstable for quite a while, no problems yet.
IMO Adrian Bunk has made one of the best Bakport Sites I knew, 
always good for fishing interesting Backport Packages.
Which KDE 3.1.2 do you use better which installation source? 

deb http://download.kde.org/stable/3.1.2/Debian stable main

deb ftp://ftp.de.debian.org/debian  unstable main non-free contrib

deb http://wh9.tu-dresden.de/kde3/karolina ./ 
It may cause problems using Karolina's KDE Packages, so did I ;o)

Bye,
Thomas

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-28, 15:52 GMT, Thomas Templin wrote:
 Which KDE 3.1.2 do you use better which installation source? 
 
 deb http://download.kde.org/stable/3.1.2/Debian stable main

This one.

 deb ftp://ftp.de.debian.org/debian  unstable main non-free contrib
 
 deb http://wh9.tu-dresden.de/kde3/karolina ./ 
 It may cause problems using Karolina's KDE Packages, so did I ;o)

I am now compiling QContentPane, so I will probably leave it there, but
I may try your site later. Thanks for providing it!

Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-25, 18:03 GMT, Matej Cepl wrote:
> On 2003-06-25, 08:27 GMT, Jean-Marc Lasgouttes wrote:
>> You need at least automake 1.5 to compile LyX for Qt (this does not
>> apply if you did not run autogen.sh, of course).
> 
> OK, I did everything seems to be OK up to this point (John? It is
> probably your patch, isn't it?):

I temporarily gave up on the John's patch, so I am going to
compile just plain LyX with Qt. When running ./autogen.sh (with
automake 1.5) it gives me these warnings:

   configure.ac:6: warning: do not use m4_patsubst: use patsubst \
  or m4_bpatsubst
   configure.ac:389: warning: do not use m4_regexp: use regexp \
  or m4_bregexp

Is it something I (or developers) should be concerned about?

I will report, whether I have succeeded.

   Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Compilation problem with Debian

[Thomas Templin]

On Wednesday 25 June 2003 04:54, Matej Cepl wrote:
> Trying to compile lyx with Qt with Qt3 (patched with ct.1.3-diff
> patch). Configure goes without problems, but compilation aborts
> with this (no error in previous compilations):
[...]
You may find a lyx-qt and a lyx-xforms Debian Package at:
deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib \ 
non-free

Perhaps this will comply your needs 

Bye,
Thomas

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-28, 14:36 GMT, Thomas Templin wrote:
> On Wednesday 25 June 2003 04:54, Matej Cepl wrote:
>> Trying to compile lyx with Qt with Qt3 (patched with ct.1.3-diff
>> patch). Configure goes without problems, but compilation aborts
>> with this (no error in previous compilations):
> [...]
> You may find a lyx-qt and a lyx-xforms Debian Package at:
> deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib \ 
> non-free

Unfortunately, I have installed KDE 3.1.2 here and it somehow breaks AA
in lyx-qt build for KDE 2.2.*.

   Thanks for the offer though,

  Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Compilation problem with Debian

[Thomas Templin]

On Saturday 28 June 2003 17:32, Matej Cepl wrote:
> On 2003-06-28, 14:36 GMT, Thomas Templin wrote:
> > On Wednesday 25 June 2003 04:54, Matej Cepl wrote:
> >> Trying to compile lyx with Qt with Qt3 (patched with
> >> ct.1.3-diff patch). Configure goes without problems, but
> >> compilation aborts with this (no error in previous
> >> compilations):
> >
> > [...]
> > You may find a lyx-qt and a lyx-xforms Debian Package at:
> > deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main
> > contrib \ non-free
>
> Unfortunately, I have installed KDE 3.1.2 here and it somehow
> breaks AA in lyx-qt build for KDE 2.2.*.
That deb's are for KDE 3.1.2, Im using them with KDE 3.1.2 stable 
and unstable for quite a while, no problems yet.
IMO Adrian Bunk has made one of the best Bakport Sites I knew, 
always good for fishing interesting Backport Packages.
Which KDE 3.1.2 do you use better which installation source? 

deb http://download.kde.org/stable/3.1.2/Debian stable main

deb ftp://ftp.de.debian.org/debian  unstable main non-free contrib

deb http://wh9.tu-dresden.de/kde3/karolina ./ 
It may cause problems using Karolina's KDE Packages, so did I ;o)

Bye,
Thomas

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-28, 15:52 GMT, Thomas Templin wrote:
> Which KDE 3.1.2 do you use better which installation source? 
> 
> deb http://download.kde.org/stable/3.1.2/Debian stable main

This one.

> deb ftp://ftp.de.debian.org/debian  unstable main non-free contrib
> 
> deb http://wh9.tu-dresden.de/kde3/karolina ./ 
> It may cause problems using Karolina's KDE Packages, so did I ;o)

I am now compiling QContentPane, so I will probably leave it there, but
I may try your site later. Thanks for providing it!

Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Andre Poenitz]

On Tue, Jun 24, 2003 at 10:22:43PM +0200, Alfredo Braunstein wrote:
 maybe somethig like (using bash, from within the src/ directory, untested):
 
 for x in `grep -l ControlRef {,*/,*/*/}*.{C,h}`; do echo $x; mv $x $x.save;
 cat $x.save | sed s/ControlRef/ControlLyXRef/g  $x; done
 
 will do. 
 
 (if something fails, original files should have a .save appended)

perl -p -i.save -e 's/ControlRef/ControlLyXRef/g' {,*/,*/*/}*.{C,h}

should do the same thing

Andre', never using the '.save', though...

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Compilation problem with Debian

[Jean-Marc Lasgouttes]

 Matej == Matej Cepl [EMAIL PROTECTED] writes:

Matej Trying to compile lyx with Qt with Qt3 (patched with
Matej ct.1.3-diff patch). Configure goes without problems, but
Matej compilation aborts with this (no error in previous
Matej compilations):
[...]
Matej What's wrong and what should I do?

You need at least automake 1.5 to compile LyX for Qt (this does not
apply if you did not run autogen.sh, of course).

JMarc

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-25, 08:27 GMT, Jean-Marc Lasgouttes wrote:
 You need at least automake 1.5 to compile LyX for Qt (this does not
 apply if you did not run autogen.sh, of course).

OK, I did everything seems to be OK up to this point (John? It is
probably your patch, isn't it?):

   dh_testdir
   # Add here commands to compile the package.
   /usr/bin/make
   make[1]: Entering directory `/home/matej/WP/lyx-1.3.2'
   Making all in config
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/config'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/config'
   Making all in development
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/development'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/development'
   Making all in intl
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/intl'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/intl'
   Making all in po
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/po'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/po'
   Making all in boost
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/boost'
   Making all in libs
   make[3]: Entering directory `/home/matej/WP/lyx-1.3.2/boost/libs'
   Making all in regex
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   Making all in src
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex/src'
   make[5]: Nothing to be done for `all'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex/src'
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   make[5]: Nothing to be done for `all-am'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   Making all in signals
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   Making all in src
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals/src'
   make[5]: Nothing to be done for `all'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals/src'
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   make[5]: Nothing to be done for `all-am'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs'
   make[4]: Nothing to be done for `all-am'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs'
   make[3]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs'
   make[3]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost'
   make[3]: Nothing to be done for `all-am'.
   make[3]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost'
   make[2]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost'
   Making all in src
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/src'
   /usr/bin/make  all-recursive
   make[3]: Entering directory `/home/matej/WP/lyx-1.3.2/src'
   Making all in mathed
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/mathed'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/mathed'
   Making all in insets
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/insets'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/insets'
   Making all in graphics
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/graphics'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/graphics'
   Making all in support
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/support'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/support'
   Making all in frontends
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends'
   Making all in controllers
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/controllers'
   make[5]: Nothing to be done for `all'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/controllers'
   Making all in qt2
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/qt2'
   Making all in ui
   make[6]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/qt2/ui'
   Making all in .
   make[7]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/qt2/ui'
   make[7]: Nothing to be done for `all-am'.
   make[7]: Leaving directory \
 

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Andre Poenitz]

On Tue, Jun 24, 2003 at 10:22:43PM +0200, Alfredo Braunstein wrote:
 maybe somethig like (using bash, from within the src/ directory, untested):
 
 for x in `grep -l ControlRef {,*/,*/*/}*.{C,h}`; do echo $x; mv $x $x.save;
 cat $x.save | sed s/ControlRef/ControlLyXRef/g  $x; done
 
 will do. 
 
 (if something fails, original files should have a .save appended)

perl -p -i.save -e 's/ControlRef/ControlLyXRef/g' {,*/,*/*/}*.{C,h}

should do the same thing

Andre', never using the '.save', though...

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Compilation problem with Debian

[Jean-Marc Lasgouttes]

 Matej == Matej Cepl [EMAIL PROTECTED] writes:

Matej Trying to compile lyx with Qt with Qt3 (patched with
Matej ct.1.3-diff patch). Configure goes without problems, but
Matej compilation aborts with this (no error in previous
Matej compilations):
[...]
Matej What's wrong and what should I do?

You need at least automake 1.5 to compile LyX for Qt (this does not
apply if you did not run autogen.sh, of course).

JMarc

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-25, 08:27 GMT, Jean-Marc Lasgouttes wrote:
 You need at least automake 1.5 to compile LyX for Qt (this does not
 apply if you did not run autogen.sh, of course).

OK, I did everything seems to be OK up to this point (John? It is
probably your patch, isn't it?):

   dh_testdir
   # Add here commands to compile the package.
   /usr/bin/make
   make[1]: Entering directory `/home/matej/WP/lyx-1.3.2'
   Making all in config
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/config'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/config'
   Making all in development
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/development'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/development'
   Making all in intl
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/intl'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/intl'
   Making all in po
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/po'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/po'
   Making all in boost
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/boost'
   Making all in libs
   make[3]: Entering directory `/home/matej/WP/lyx-1.3.2/boost/libs'
   Making all in regex
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   Making all in src
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex/src'
   make[5]: Nothing to be done for `all'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex/src'
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   make[5]: Nothing to be done for `all-am'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   Making all in signals
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   Making all in src
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals/src'
   make[5]: Nothing to be done for `all'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals/src'
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   make[5]: Nothing to be done for `all-am'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs'
   make[4]: Nothing to be done for `all-am'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs'
   make[3]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs'
   make[3]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost'
   make[3]: Nothing to be done for `all-am'.
   make[3]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost'
   make[2]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost'
   Making all in src
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/src'
   /usr/bin/make  all-recursive
   make[3]: Entering directory `/home/matej/WP/lyx-1.3.2/src'
   Making all in mathed
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/mathed'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/mathed'
   Making all in insets
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/insets'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/insets'
   Making all in graphics
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/graphics'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/graphics'
   Making all in support
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/support'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/support'
   Making all in frontends
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends'
   Making all in controllers
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/controllers'
   make[5]: Nothing to be done for `all'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/controllers'
   Making all in qt2
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/qt2'
   Making all in ui
   make[6]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/qt2/ui'
   Making all in .
   make[7]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/qt2/ui'
   make[7]: Nothing to be done for `all-am'.
   make[7]: Leaving directory \
 

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Andre Poenitz]

On Tue, Jun 24, 2003 at 10:22:43PM +0200, Alfredo Braunstein wrote:
> maybe somethig like (using bash, from within the src/ directory, untested):
> 
> for x in `grep -l ControlRef {,*/,*/*/}*.{C,h}`; do echo $x; mv $x $x.save;
> cat $x.save | sed s/ControlRef/ControlLyXRef/g > $x; done
> 
> will do. 
> 
> (if something fails, original files should have a .save appended)

perl -p -i.save -e 's/ControlRef/ControlLyXRef/g' {,*/,*/*/}*.{C,h}

should do the same thing

Andre', never using the '.save', though...

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Compilation problem with Debian

[Jean-Marc Lasgouttes]

> "Matej" == Matej Cepl <[EMAIL PROTECTED]> writes:

Matej> Trying to compile lyx with Qt with Qt3 (patched with
Matej> ct.1.3-diff patch). Configure goes without problems, but
Matej> compilation aborts with this (no error in previous
Matej> compilations):
[...]
Matej> What's wrong and what should I do?

You need at least automake 1.5 to compile LyX for Qt (this does not
apply if you did not run autogen.sh, of course).

JMarc

Re: Compilation problem with Debian

[Matej Cepl]

On 2003-06-25, 08:27 GMT, Jean-Marc Lasgouttes wrote:
> You need at least automake 1.5 to compile LyX for Qt (this does not
> apply if you did not run autogen.sh, of course).

OK, I did everything seems to be OK up to this point (John? It is
probably your patch, isn't it?):

   dh_testdir
   # Add here commands to compile the package.
   /usr/bin/make
   make[1]: Entering directory `/home/matej/WP/lyx-1.3.2'
   Making all in config
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/config'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/config'
   Making all in development
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/development'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/development'
   Making all in intl
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/intl'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/intl'
   Making all in po
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/po'
   make[2]: Nothing to be done for `all'.
   make[2]: Leaving directory `/home/matej/WP/lyx-1.3.2/po'
   Making all in boost
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/boost'
   Making all in libs
   make[3]: Entering directory `/home/matej/WP/lyx-1.3.2/boost/libs'
   Making all in regex
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   Making all in src
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex/src'
   make[5]: Nothing to be done for `all'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex/src'
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   make[5]: Nothing to be done for `all-am'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/regex'
   Making all in signals
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   Making all in src
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals/src'
   make[5]: Nothing to be done for `all'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals/src'
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   make[5]: Nothing to be done for `all-am'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs/signals'
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs'
   make[4]: Nothing to be done for `all-am'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs'
   make[3]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost/libs'
   make[3]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/boost'
   make[3]: Nothing to be done for `all-am'.
   make[3]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost'
   make[2]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/boost'
   Making all in src
   make[2]: Entering directory `/home/matej/WP/lyx-1.3.2/src'
   /usr/bin/make  all-recursive
   make[3]: Entering directory `/home/matej/WP/lyx-1.3.2/src'
   Making all in mathed
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/mathed'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/mathed'
   Making all in insets
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/insets'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/insets'
   Making all in graphics
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/graphics'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/graphics'
   Making all in support
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/support'
   make[4]: Nothing to be done for `all'.
   make[4]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/support'
   Making all in frontends
   make[4]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends'
   Making all in controllers
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/controllers'
   make[5]: Nothing to be done for `all'.
   make[5]: Leaving directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/controllers'
   Making all in qt2
   make[5]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/qt2'
   Making all in ui
   make[6]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/qt2/ui'
   Making all in .
   make[7]: Entering directory \
  `/home/matej/WP/lyx-1.3.2/src/frontends/qt2/ui'
   make[7]: Nothing to be done for `all-am'.
   make[7]: Leaving directory 

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Juergen Spitzmueller]

Ronald Florence wrote:
 /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
 types for `typedef struct OpaqueControlRef * ControlRef'
 ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
 `class ControlRef'

As far as I understand it, this is a naming clash. Qt has a 
typedef struct OpaqueControlRef *ControlRef;
defined in its headers (qwindowdefs.h) which is used only with Mac (it is 
inside a #if defined(Q_WS_MAC) clause). This seems to clash with LyX's 
ControlRef. Does it help if you change LyX's ControlRef and all instances to 
ControlLyXRef or something?

Juergen. 

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Alfredo Braunstein]

Juergen Spitzmueller wrote:

 ControlRef. Does it help if you change LyX's ControlRef and all instances
 to ControlLyXRef or something?

adding 

#define ControlRef ControlLyXRef 

to the top of src/frontends/controllers/ControlRef.h may just work...

Regards, Alfredo

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Ronald Florence]

Alfredo Braunstein [EMAIL PROTECTED] writes:

 Juergen Spitzmueller wrote:
 
  ControlRef. Does it help if you change LyX's ControlRef and all instances
  to ControlLyXRef or something?
 
 adding 
 
 #define ControlRef ControlLyXRef 
 
 to the top of src/frontends/controllers/ControlRef.h may just work...

Thanks to Juergen and Alfredo.  This gets close, but the compile of
lyx-1.3.2 later gags at:


In file included from /usr/local/src/qt-mac-free-3.1.2/include/qfont.h:42,
 from Qt2Base.h:22,
 from QAbout.h:19,
 from Dialogs_impl.h:54,
 from Dialogs.C:19:
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting types for 
`typedef struct OpaqueControlRef * ControlLyXRef'
../../../src/frontends/controllers/ControlRef.h:45: previous declaration as `class 
ControlLyXRef'
../../../src/frontends/controllers/GUI.h: In method `GUIOpaqueControlRef 
*,QRef,NoRepeatedApplyReadOnlyPolicy,Qt2BC::GUI(LyXView , Dialogs )':
Dialogs.C:82:   instantiated from here
../../../src/frontends/controllers/GUI.h:44: warning: initializer list treated as 
compound expression
../../../src/frontends/controllers/GUI.h:44: invalid use of undefined type `class 
LyXView'
../../../src/frontends/Dialogs.h:25: forward declaration of `class LyXView'
../../../src/frontends/controllers/GUI.h:47: request for member `setView' in 
`GUIOpaqueControlRef *,QRef,NoRepeatedApplyReadOnlyPolicy,Qt2BC::controller_', which 
is of non-aggregate type `OpaqueControlRef *'
../../../src/frontends/controllers/GUI.h:48: request for member `setButtonController' 
in `GUIOpaqueControlRef *,QRef,NoRepeatedApplyReadOnlyPolicy,Qt2BC::controller_', 
which is of non-aggregate type `OpaqueControlRef *'
../../../src/frontends/controllers/GUI.h:49: no matching function for call to 
`QRef::setController (OpaqueControlRef *)'
../../../src/frontends/controllers/ViewBase.h:53: candidates are: void 
ViewBase::setController(ControlButtons )
make[2]: *** [Dialogs.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1


I'd welcome further suggestions.  Regards,

-- 

Ronald Florence www.18james.com

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Alfredo Braunstein]

Ronald Florence wrote:

 Alfredo Braunstein [EMAIL PROTECTED] writes:
 
 Juergen Spitzmueller wrote:
 
  ControlRef. Does it help if you change LyX's ControlRef and all
  instances to ControlLyXRef or something?
 
 adding
 
 #define ControlRef ControlLyXRef
 
 to the top of src/frontends/controllers/ControlRef.h may just work...
 
 Thanks to Juergen and Alfredo.  This gets close, but the compile of
 lyx-1.3.2 later gags at:

Then this hack is no good... your can try directly Juergen's suggestion.

maybe somethig like (using bash, from within the src/ directory, untested):

for x in `grep -l ControlRef {,*/,*/*/}*.{C,h}`; do echo $x; mv $x $x.save;
cat $x.save | sed s/ControlRef/ControlLyXRef/g  $x; done

will do. 

(if something fails, original files should have a .save appended)

Hope it helps,

Alfredo

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Juergen Spitzmueller]

Ronald Florence wrote:
 /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
 types for `typedef struct OpaqueControlRef * ControlRef'
 ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
 `class ControlRef'

As far as I understand it, this is a naming clash. Qt has a 
typedef struct OpaqueControlRef *ControlRef;
defined in its headers (qwindowdefs.h) which is used only with Mac (it is 
inside a #if defined(Q_WS_MAC) clause). This seems to clash with LyX's 
ControlRef. Does it help if you change LyX's ControlRef and all instances to 
ControlLyXRef or something?

Juergen. 

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Alfredo Braunstein]

Juergen Spitzmueller wrote:

 ControlRef. Does it help if you change LyX's ControlRef and all instances
 to ControlLyXRef or something?

adding 

#define ControlRef ControlLyXRef 

to the top of src/frontends/controllers/ControlRef.h may just work...

Regards, Alfredo

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Ronald Florence]

Alfredo Braunstein [EMAIL PROTECTED] writes:

 Juergen Spitzmueller wrote:
 
  ControlRef. Does it help if you change LyX's ControlRef and all instances
  to ControlLyXRef or something?
 
 adding 
 
 #define ControlRef ControlLyXRef 
 
 to the top of src/frontends/controllers/ControlRef.h may just work...

Thanks to Juergen and Alfredo.  This gets close, but the compile of
lyx-1.3.2 later gags at:


In file included from /usr/local/src/qt-mac-free-3.1.2/include/qfont.h:42,
 from Qt2Base.h:22,
 from QAbout.h:19,
 from Dialogs_impl.h:54,
 from Dialogs.C:19:
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting types for 
`typedef struct OpaqueControlRef * ControlLyXRef'
../../../src/frontends/controllers/ControlRef.h:45: previous declaration as `class 
ControlLyXRef'
../../../src/frontends/controllers/GUI.h: In method `GUIOpaqueControlRef 
*,QRef,NoRepeatedApplyReadOnlyPolicy,Qt2BC::GUI(LyXView , Dialogs )':
Dialogs.C:82:   instantiated from here
../../../src/frontends/controllers/GUI.h:44: warning: initializer list treated as 
compound expression
../../../src/frontends/controllers/GUI.h:44: invalid use of undefined type `class 
LyXView'
../../../src/frontends/Dialogs.h:25: forward declaration of `class LyXView'
../../../src/frontends/controllers/GUI.h:47: request for member `setView' in 
`GUIOpaqueControlRef *,QRef,NoRepeatedApplyReadOnlyPolicy,Qt2BC::controller_', which 
is of non-aggregate type `OpaqueControlRef *'
../../../src/frontends/controllers/GUI.h:48: request for member `setButtonController' 
in `GUIOpaqueControlRef *,QRef,NoRepeatedApplyReadOnlyPolicy,Qt2BC::controller_', 
which is of non-aggregate type `OpaqueControlRef *'
../../../src/frontends/controllers/GUI.h:49: no matching function for call to 
`QRef::setController (OpaqueControlRef *)'
../../../src/frontends/controllers/ViewBase.h:53: candidates are: void 
ViewBase::setController(ControlButtons )
make[2]: *** [Dialogs.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1


I'd welcome further suggestions.  Regards,

-- 

Ronald Florence www.18james.com

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Alfredo Braunstein]

Ronald Florence wrote:

 Alfredo Braunstein [EMAIL PROTECTED] writes:
 
 Juergen Spitzmueller wrote:
 
  ControlRef. Does it help if you change LyX's ControlRef and all
  instances to ControlLyXRef or something?
 
 adding
 
 #define ControlRef ControlLyXRef
 
 to the top of src/frontends/controllers/ControlRef.h may just work...
 
 Thanks to Juergen and Alfredo.  This gets close, but the compile of
 lyx-1.3.2 later gags at:

Then this hack is no good... your can try directly Juergen's suggestion.

maybe somethig like (using bash, from within the src/ directory, untested):

for x in `grep -l ControlRef {,*/,*/*/}*.{C,h}`; do echo $x; mv $x $x.save;
cat $x.save | sed s/ControlRef/ControlLyXRef/g  $x; done

will do. 

(if something fails, original files should have a .save appended)

Hope it helps,

Alfredo

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Juergen Spitzmueller]

Ronald Florence wrote:
> /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
> types for `typedef struct OpaqueControlRef * ControlRef'
> ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
> `class ControlRef'

As far as I understand it, this is a naming clash. Qt has a 
typedef struct OpaqueControlRef *ControlRef;
defined in its headers (qwindowdefs.h) which is used only with Mac (it is 
inside a #if defined(Q_WS_MAC) clause). This seems to clash with LyX's 
ControlRef. Does it help if you change LyX's ControlRef and all instances to 
ControlLyXRef or something?

Juergen. 

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Alfredo Braunstein]

Juergen Spitzmueller wrote:

> ControlRef. Does it help if you change LyX's ControlRef and all instances
> to ControlLyXRef or something?

adding 

#define ControlRef ControlLyXRef 

to the top of src/frontends/controllers/ControlRef.h may just work...

Regards, Alfredo

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Ronald Florence]

Alfredo Braunstein <[EMAIL PROTECTED]> writes:

> Juergen Spitzmueller wrote:
> 
> > ControlRef. Does it help if you change LyX's ControlRef and all instances
> > to ControlLyXRef or something?
> 
> adding 
> 
> #define ControlRef ControlLyXRef 
> 
> to the top of src/frontends/controllers/ControlRef.h may just work...

Thanks to Juergen and Alfredo.  This gets close, but the compile of
lyx-1.3.2 later gags at:


In file included from /usr/local/src/qt-mac-free-3.1.2/include/qfont.h:42,
 from Qt2Base.h:22,
 from QAbout.h:19,
 from Dialogs_impl.h:54,
 from Dialogs.C:19:
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting types for 
`typedef struct OpaqueControlRef * ControlLyXRef'
../../../src/frontends/controllers/ControlRef.h:45: previous declaration as `class 
ControlLyXRef'
../../../src/frontends/controllers/GUI.h: In method `GUI::GUI(LyXView &, Dialogs &)':
Dialogs.C:82:   instantiated from here
../../../src/frontends/controllers/GUI.h:44: warning: initializer list treated as 
compound expression
../../../src/frontends/controllers/GUI.h:44: invalid use of undefined type `class 
LyXView'
../../../src/frontends/Dialogs.h:25: forward declaration of `class LyXView'
../../../src/frontends/controllers/GUI.h:47: request for member `setView' in 
`GUI::controller_', which 
is of non-aggregate type `OpaqueControlRef *'
../../../src/frontends/controllers/GUI.h:48: request for member `setButtonController' 
in `GUI::controller_', 
which is of non-aggregate type `OpaqueControlRef *'
../../../src/frontends/controllers/GUI.h:49: no matching function for call to 
`QRef::setController (OpaqueControlRef *&)'
../../../src/frontends/controllers/ViewBase.h:53: candidates are: void 
ViewBase::setController(ControlButtons &)
make[2]: *** [Dialogs.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1


I'd welcome further suggestions.  Regards,

-- 

Ronald Florence www.18james.com

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Alfredo Braunstein]

Ronald Florence wrote:

> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> 
>> Juergen Spitzmueller wrote:
>> 
>> > ControlRef. Does it help if you change LyX's ControlRef and all
>> > instances to ControlLyXRef or something?
>> 
>> adding
>> 
>> #define ControlRef ControlLyXRef
>> 
>> to the top of src/frontends/controllers/ControlRef.h may just work...
> 
> Thanks to Juergen and Alfredo.  This gets close, but the compile of
> lyx-1.3.2 later gags at:

Then this hack is no good... your can try directly Juergen's suggestion.

maybe somethig like (using bash, from within the src/ directory, untested):

for x in `grep -l ControlRef {,*/,*/*/}*.{C,h}`; do echo $x; mv $x $x.save;
cat $x.save | sed s/ControlRef/ControlLyXRef/g > $x; done

will do. 

(if something fails, original files should have a .save appended)

Hope it helps,

Alfredo