Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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
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
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
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
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: Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
On Wed, Jul 02, 2003 at 02:03:19PM +0900, Jan Peters wrote: I mailed Trolltech about the discussion, and there reply is: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. This is ambiguous about whether they fixed it in their tree or not, can you please push them on this ? However, using ControlRef might be a bad idea in any event as it is a type in Carbon so including some headers could indeed pull it in otherwise. Irrelevant I suspect... regards john
Re: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
I mailed Trolltech about the discussion, and there reply is: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. This is ambiguous about whether they fixed it in their tree or not, can you please push them on this ? Ok, I will! However, using ControlRef might be a bad idea in any event as it is a type in Carbon so including some headers could indeed pull it in otherwise. Irrelevant I suspect... For us, yes! Best, -Jan
Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
NEWS FROM TROLLTECH: On Wednesday, 02. Jul 2003 22:33 Jan Peters wrote: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. Hi Sam! Will you remove this ControlRef then from your tree? Or will it stay? Yes, it has been removed. I do not believe it will reappear either (its use has moved out of Qt itself). Regards //Sam -- Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway
Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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
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: Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
On Wed, Jul 02, 2003 at 02:03:19PM +0900, Jan Peters wrote: I mailed Trolltech about the discussion, and there reply is: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. This is ambiguous about whether they fixed it in their tree or not, can you please push them on this ? However, using ControlRef might be a bad idea in any event as it is a type in Carbon so including some headers could indeed pull it in otherwise. Irrelevant I suspect... regards john
Re: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
I mailed Trolltech about the discussion, and there reply is: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. This is ambiguous about whether they fixed it in their tree or not, can you please push them on this ? Ok, I will! However, using ControlRef might be a bad idea in any event as it is a type in Carbon so including some headers could indeed pull it in otherwise. Irrelevant I suspect... For us, yes! Best, -Jan
Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
NEWS FROM TROLLTECH: On Wednesday, 02. Jul 2003 22:33 Jan Peters wrote: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. Hi Sam! Will you remove this ControlRef then from your tree? Or will it stay? Yes, it has been removed. I do not believe it will reappear either (its use has moved out of Qt itself). Regards //Sam -- Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway
Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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
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: Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
On Wed, Jul 02, 2003 at 02:03:19PM +0900, Jan Peters wrote: > I mailed Trolltech about the discussion, and there reply is: > > >I agree, you can safely remove it from qwindowdefs.h. Originally it was > >thought to be necessary for future plans, but not. This is ambiguous about whether they fixed it in their tree or not, can you please push them on this ? > >However, using ControlRef might be a bad idea in any event as it is a > >type in Carbon so including some headers could indeed pull it in > >otherwise. Irrelevant I suspect... regards john
Re: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
I mailed Trolltech about the discussion, and there reply is: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. This is ambiguous about whether they fixed it in their tree or not, can you please push them on this ? Ok, I will! However, using ControlRef might be a bad idea in any event as it is a type in Carbon so including some headers could indeed pull it in otherwise. Irrelevant I suspect... For us, yes! Best, -Jan
Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
NEWS FROM TROLLTECH: On Wednesday, 02. Jul 2003 22:33 Jan Peters wrote: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. Hi Sam! Will you remove this ControlRef then from your tree? Or will it stay? Yes, it has been removed. I do not believe it will reappear either (its use has moved out of Qt itself). Regards //Sam -- Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway
Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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
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
/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
Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
I mailed Trolltech about the discussion, and there reply is: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. However, using ControlRef might be a bad idea in any event as it is a type in Carbon so including some headers could indeed pull it in otherwise. Regards //Sam
Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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
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
/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
Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
I mailed Trolltech about the discussion, and there reply is: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. However, using ControlRef might be a bad idea in any event as it is a type in Carbon so including some headers could indeed pull it in otherwise. Regards //Sam
Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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
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
/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
Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries
I mailed Trolltech about the discussion, and there reply is: I agree, you can safely remove it from qwindowdefs.h. Originally it was thought to be necessary for future plans, but not. However, using ControlRef might be a bad idea in any event as it is a type in Carbon so including some headers could indeed pull it in otherwise. Regards //Sam
Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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 Trolltech MacOSX/GPL QT libraries
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 Trolltech MacOSX/GPL QT libraries
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...)
compilation problem with Trolltech MacOSX/GPL QT libraries
I've succeeded in compiling the Trolltech MacOSX (GPL) Qt libraries with gcc-2.95.2, but something in their header files gags the LyX-1.3.2 compile with the same compiler. 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 * ControlRef' ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as `class ControlRef' ../../../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[5]: *** [Dialogs.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 I'll be glad to supply additional information if anyone could suggest a workaround to this glitch. Thanks, -- Ronald Florence www.18james.com
Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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
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
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
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
compilation problem with Trolltech MacOSX/GPL QT libraries
I've succeeded in compiling the Trolltech MacOSX (GPL) Qt libraries with gcc-2.95.2, but something in their header files gags the LyX-1.3.2 compile with the same compiler. 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 * ControlRef' ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as `class ControlRef' ../../../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[5]: *** [Dialogs.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 I'll be glad to supply additional information if anyone could suggest a workaround to this glitch. Thanks, -- Ronald Florence www.18james.com
Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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
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
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
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
compilation problem with Trolltech MacOSX/GPL QT libraries
I've succeeded in compiling the Trolltech MacOSX (GPL) Qt libraries with gcc-2.95.2, but something in their header files gags the LyX-1.3.2 compile with the same compiler. 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 * ControlRef' ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as `class ControlRef' ../../../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[5]: *** [Dialogs.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 I'll be glad to supply additional information if anyone could suggest a workaround to this glitch. Thanks, -- Ronald Florence www.18james.com
Re: compilation problem with Trolltech MacOSX/GPL QT libraries
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
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
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
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
