Maybe debug and release are mixed up in the generated Visual C++
projects? I noticed there is only a debug build option.
The msvs projects do not really know the mode of the build process and
I just mark them as 'debug'. That is to say, you can generate the
projects with mode=release and build.
Bo Peng wrote:
It looks like the fix works after all, something was wrong with
rebuilding.
You mean the current svn is working well? That is good, although your
claim has a tendency to compromise the reputation of lyx/scons. :-)
Yes, the current SVN works.
Maybe debug and release are mixed u
It looks like the fix works after all, something was wrong with rebuilding.
You mean the current svn is working well? That is good, although your
claim has a tendency to compromise the reputation of lyx/scons. :-)
Bo
Georg Baum wrote:
Joost Verburg wrote:
The qt3 frontend of 1.5 doesn't crash for me. Maybe the fix is already
there and should be copied to branch?
Maybe. If you want to find out you have to compare...
It looks like the fix works after all, something was wrong with rebuilding.
Now I need t
Joost Verburg wrote:
> The qt3 frontend of 1.5 doesn't crash for me. Maybe the fix is already
> there and should be copied to branch?
Maybe. If you want to find out you have to compare...
Georg
Georg Baum wrote:
What I do remember is that the crash on exit problem on windows has not been
finally fixed in trunk, we still have the workaround of a static
Application object in qt4. That should not be needed, but we don't know why
it crashes if the global application object is not static.
Ma
Bo Peng wrote:
> I can not answer this question since I never touched the socket
> code Georg, do you remember anything?
What I do remember is that the crash on exit problem on windows has not been
finally fixed in trunk, we still have the workaround of a static
Application object in qt4. Tha
I copied lyxsocket.C from trunk, but that makes no difference. The crash
however is related to this socket thing.
It is expected since the patch was only an additional error check.
In lyx_gui.C, the crash happens when deleting lyxsocket:
void cleanup()
{
delete lyxsocket; <<< crash he
Bo Peng wrote:
No idea now. The follow patch will sync lyxsocket.C with the trunk,
but it should not matter. Can you try? (Just copy lyxsocket.C from
trunk to branch).
I copied lyxsocket.C from trunk, but that makes no difference. The crash
however is related to this socket thing.
In lyx_gui
> Fixed (14786), with the following code copied from trunk.
It's not fixed completely. Now it crashes in lyx_gui.C line 98.
No idea now. The follow patch will sync lyxsocket.C with the trunk,
but it should not matter. Can you try? (Just copy lyxsocket.C from
trunk to branch).
You can see that
Bo Peng wrote:
The next problem is a crash when LyX 1.4 is closed, in lyxsocket.C
line 79.
Fixed (14786), with the following code copied from trunk.
It's not fixed completely. Now it crashes in lyx_gui.C line 98.
Joost
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> JMarc, sorry that I did not wait for your approval for 14786. I am
Bo> in a hurry and the patch is obvious enough.
That is OK.
JMarc
There are two more locations in messages.C where this should be fixed.
Fixed. (14785)
The next problem is a crash when LyX 1.4 is closed, in lyxsocket.C line 79.
Fixed (14786), with the following code copied from trunk.
Index: src/lyxsocket.C
Bo Peng wrote:
The following patch is copied from the trunk, and should fix this
problem. Can I apply?
There are two more locations in messages.C where this should be fixed.
The next problem is a crash when LyX 1.4 is closed, in lyxsocket.C line 79.
Joost
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Is LC_MESSAGES defined to something reasonable? can setlocale
>> accept the NULL?
Bo> The following patch is copied from the trunk, and should fix this
Bo> problem. Can I apply?
Hmm, what is strange is that GNU gettext intl.h does define
LC_ME
Michael Gerz wrote:
| If I understand correctly, even Lars is willing to ditch qt3 under
| certain conditions. Lars, are these conditions already fulfilled?
Not quite. I'd like to see the conversion to qt4 finished properly so
that we can ditch -DQT3_SUPPORT.
We don't evne link with libQt3Suppo
Is LC_MESSAGES defined to something reasonable? can setlocale accept
the NULL?
The following patch is copied from the trunk, and should fix this
problem. Can I apply?
Bo
Index: src/messages.C
===
--- src/messages.C (revision
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:
Joost> Jean-Marc Lasgouttes wrote: So there must be a difference
Joost> between 1.4 and 1.5 that explains why 1.4 crashes.
>> Can you get a backtrace?
Joost> The crash happens in messages.C line 93.
So windows does not like this
Jean-Marc Lasgouttes wrote:
Joost> So there must be a difference between 1.4 and 1.5 that explains
Joost> why 1.4 crashes.
Can you get a backtrace?
The crash happens in messages.C line 93.
Joost
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> If you promise to not tell anybody I can tell you that we do
Georg> the same in qt4 already ;-)
Do we? Naughty us.
Georg> This patch fixes the aut* stuff and went right now.
Thanks a lot.
Jmarc
Am Donnerstag, 17. August 2006 00:57 schrieb Jean-Marc Lasgouttes:
> Hmm, you #include .cpp files, while what we have is .C...
>
> Of course we could generate _moc.cpp, but we did not do the big
> extension change yet.
If you promise to not tell anybody I can tell you that we do the same in
qt4
Jean-Marc Lasgouttes wrote:
Can you get a backtrace?
I'm currently creating a debug version.
Joost
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> OK. Here is what I can do:
>>
>> 1. apply the current patch (with added config.h). 2. apply relevant
>> part (scons) of the patch to the trunk. 3. add _moc.cpp to .C files
>> for qt3, as we did for qt4 (trunk only) 4. Georg adjusts
>> makefile.
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:
Joost> Bo Peng wrote:
>> 1, 2, 3 are applied (tested under linux). It is Georg's turn to do
>> 4. Patch for 5 is attached (tested under linux). If 4 is fine,
>> Georg can add Makefile.am changes to the patch and apply.
Joost> Both 1.4 and
Bo Peng wrote:
1, 2, 3 are applied (tested under linux). It is Georg's turn to do 4.
Patch for 5 is attached (tested under linux). If 4 is fine, Georg can
add Makefile.am changes to the patch and apply.
Both 1.4 and 1.5 now compile with MSVC 2005. While 1.4 crashes
immediately, 1.5 does start
OK. Here is what I can do:
1. apply the current patch (with added config.h).
2. apply relevant part (scons) of the patch to the trunk.
3. add _moc.cpp to .C files for qt3, as we did for qt4 (trunk only)
4. Georg adjusts makefile.am for the trunk and we will see if things go well.
5. port 3 and 4
I will apply both patches (1.4 and 1.5 as part of it) soon.
Done. Note that the patches are *not* tested under windows.
Bo
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > (Isn't that just hiding it under the rug?)
|
| Quite the contrary. I suspect that most of the files do no need
| QT3_SUPPORT and I would like to know which one need it.
That is easy... just compile without -DQT3_SUPPORT and see where it
breaks.
Michael Gerz wrote:
| If I understand correctly, even Lars is willing to ditch qt3 under
| certain conditions. Lars, are these conditions already fulfilled?
Not quite. I'd like to see the conversion to qt4 finished properly so
that we can ditch -DQT3_SUPPORT.
We don't evne link with libQt3Suppo
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > "Michael Gerz" <[EMAIL PROTECTED]> writes:
| > | > Abdelrazak> You guys should forget about qt3 in trunk. Just
| > | > Abdelrazak> concentrate on 1.4!
| > | >
| > | > So that you can say tha
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> OK. Here is what I can do:
Bo> 1. apply the current patch (with added config.h). 2. apply
Bo> relevant part (scons) of the patch to the trunk. 3. add _moc.cpp
Bo> to .C files for qt3, as we did for qt4 (trunk only) 4. Georg
Bo> adjusts makefil
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > "Michael Gerz" <[EMAIL PROTECTED]> writes:
| > | > Abdelrazak> You guys should forget about qt3 in trunk. Just
| > | > Abdelrazak> concentrate on 1.4!
| > | >
| > | > So that you can say that the code is not up to date
| If I understand correctly, even Lars is willing to ditch qt3 under
| certain conditions. Lars, are these conditions already fulfilled?
Not quite. I'd like to see the conversion to qt4 finished properly so
that we can ditch -DQT3_SUPPORT.
We don't evne link with libQt3Support.so so it cannot be
Lars Gullik Bjønnes wrote:
"Michael Gerz" <[EMAIL PROTECTED]> writes:
| > Abdelrazak> You guys should forget about qt3 in trunk. Just
| > Abdelrazak> concentrate on 1.4!
| >
| > So that you can say that the code is not up to date anymore... ;)
|
| Seriously, do we really want to keep the qt3 fr
"Michael Gerz" <[EMAIL PROTECTED]> writes:
| > Abdelrazak> You guys should forget about qt3 in trunk. Just
| > Abdelrazak> concentrate on 1.4!
| >
| > So that you can say that the code is not up to date anymore... ;)
|
| Seriously, do we really want to keep the qt3 frontend for 1.5? I see
| no re
I'm now trying to compile LyX 1.5svn. The qt 3 lib detection is broken
like in 1.4. Can you provide me with a 1.5 version of the patch?
That is part 2 of my plan, which has not been proved. :-)
I will apply both patches (1.4 and 1.5 as part of it) soon.
Bo
Abdelrazak> You guys should forget about qt3 in trunk. Just
Abdelrazak> concentrate on 1.4!
So that you can say that the code is not up to date anymore... ;)
Seriously, do we really want to keep the qt3 frontend for 1.5? I see no real
reason to maintain two almost identical frontends (at least
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> You guys should forget about qt3 in trunk. Just
Abdelrazak> concentrate on 1.4!
So that you can say that the code is not up to date anymore... ;)
JMarc
Bo Peng wrote:
Makefile.am changes are trivial, too. I can do them if you coud dig
out the
patch and apply it.
OK. Here is what I can do:
1. apply the current patch (with added config.h).
2. apply relevant part (scons) of the patch to the trunk.
3. add _moc.cpp to .C files for qt3, as we did
Is there someone who tried 1.5 with Q../Free 3 and MSVC 2005?
I'm now trying to compile LyX 1.5svn. The qt 3 lib detection is broken
like in 1.4. Can you provide me with a 1.5 version of the patch?
The next problem is that the linker somehow looks for boost libraries
called libboost-vc80...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> So it is QContentPane_moc.C shat should get config.h then.
|
| Lars> moc -f does not do what we want?
|
| No, this does not do that.
It does here...
/**
Makefile.am changes are trivial, too. I can do them if you coud dig out the
patch and apply it.
OK. Here is what I can do:
1. apply the current patch (with added config.h).
2. apply relevant part (scons) of the patch to the trunk.
3. add _moc.cpp to .C files for qt3, as we did for qt4 (trunk on
<[EMAIL PROTECTED]> wrote:
I now managed to compile LyX 1.4svn with MSVC 2005, but unfortunately
LyX crashes at startup without any command line output.
Not surprisingly, but I was hoping that your windows xp would work
better than mine. :-)
Bo, did you try to compile it yourself?
Yes. Lyx
Am Mittwoch, 16. August 2006 20:18 schrieb Bo Peng:
> > An other option is to do like qt4 and include the moc file in the
> > corresponding .C file. (at the end)
>
> I like this a lot better than 'moc -include'.
Me too.
> I actually had a qt3
> patch sometime ago when I did this for qt4, but no
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> So it is QContentPane_moc.C shat should get config.h then.
Lars> moc -f does not do what we want?
Jean-Marc> No, this does not do that.
Oops, I should not
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> So it is QContentPane_moc.C shat should get config.h then.
Lars> moc -f does not do what we want?
No, this does not do that.
What we could do is play sed tricks on the generated moc (and scons
could play other tricks), but th
An other option is to do like qt4 and include the moc file in the
corresponding .C file. (at the end)
I like this a lot better than 'moc -include'. I actually had a qt3
patch sometime ago when I did this for qt4, but nobody was interested.
There will be some Makefile.am changes if you guys deci
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | I a, a bit slow but I get there :)
|
| So it is QContentPane_moc.C shat should get config.h then.
|
| moc -f does not do what we want?
This does not look too bad imho:
Index: Makefile.am
===
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
|
| >> The _moc.cpp file uses boost headers? Where? Why?
|
| Bo> src/frontends/qt2/QContentPane.h, line 29, include
| Bo>
|
| Ahh, OK. QContentPane_moc.C includes QContentPane.h, which includes
I now managed to compile LyX 1.4svn with MSVC 2005, but unfortunately
LyX crashes at startup without any command line output.
Bo, did you try to compile it yourself? Is there someone who tried 1.5
with Q../Free 3 and MSVC 2005?
Joost
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> The _moc.cpp file uses boost headers? Where? Why?
Bo> src/frontends/qt2/QContentPane.h, line 29, include
Bo>
Ahh, OK. QContentPane_moc.C includes QContentPane.h, which includes
boost.
I a, a bit slow but I get there :)
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
|
|
| Bo> So are we going to use MAX_PATH everywhere? Or just for windows?
|
| Does it exist on linux? I do not think so?
|
| Bo> I actually also have a question about:
|
| Bo> #define BOOST_N
Latest patch attached, with INSTALL.scons changes. Two problems:
1. I do not have a windows machine to test the MAX_PATH, PATH_MAX thing.
2. If the removal of BOOST_NO_WREGEX causes problem on some other
platforms, we should add it back.
Cheers,
Bo
msvc-14x.diff
Description: Binary data
My problem is I do not understand where boost/scoped_ptr.hpp is added to moc
files.
There is a include "../../../../src/frontends/qt2/QContentPane.h",
which in turn includes the boost file, in the generated
QContentPane_moc.cpp.
Bo
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> > The _moc.cpp file uses boost headers? Where? Why?
>>
>> src/frontends/qt2/QContentPane.h, line 29, include
>>
Bo> BTW, if you do not like config.h, it is enough to add #define
Bo> BOOST_ALL_NO_LIB before #include .
My problem is I do not u
> The _moc.cpp file uses boost headers? Where? Why?
src/frontends/qt2/QContentPane.h, line 29, include
BTW, if you do not like config.h, it is enough to add #define
BOOST_ALL_NO_LIB before #include .
Bo
Joost Verburg wrote:
Does the SCons build system link to the static C run-time library or the
DLL version? I need to make sure that all components are linked same one.
AFAIR, under Window XP and with MSVC2005 it links to the DLLs defined in
the manifest file. You have two choices:
1) Distrib
On 8/16/06, Joost Verburg <[EMAIL PROTECTED]> wrote:
Does the SCons build system link to the static C run-time library or the
DLL version? I need to make sure that all components are linked same one.
I am not sure. :-) You will have to findout by yourself (look at the
last link command or read
On 8/16/06, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> It can not, and there is already a config.h in the .C file. The
Bo> problem is with the generated _moc.cpp file, which uses some boost
Bo> headers but does not have config.h. The co
Does the SCons build system link to the static C run-time library or the
DLL version? I need to make sure that all components are linked same one.
Joost
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> It can not, and there is already a config.h in the .C file. The
Bo> problem is with the generated _moc.cpp file, which uses some boost
Bo> headers but does not have config.h. The compiled _moc.obj then
Bo> need to link to the system boost file
On 8/16/06, Bo Peng <[EMAIL PROTECTED]> wrote:
> ===
> --- src/frontends/qt2/QContentPane.h (revision 14695)
> +++ src/frontends/qt2/QContentPane.h (working copy)
> @@ -16,6 +16,8 @@
>#undef emit
>#endif
>
> +#inc
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> I actually also have a question about:
Bo> #define BOOST_NO_WREGEX 1
Bo> which causes problem for msvc. I now remove it for linux, and lyx
Bo> compiles fine. Why do we define it in the first place?
Could we see the problem that it causes? It
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> So are we going to use MAX_PATH everywhere? Or just for windows?
Does it exist on linux? I do not think so?
Bo> I actually also have a question about:
Bo> #define BOOST_NO_WREGEX 1
Bo> which causes problem for msvc. I now remove it for lin
Bo Peng wrote:
> So are we going to use MAX_PATH everywhere?
No.
> Or just for windows?
Yes. PATH_MAX and MAX_PATH should only be used in some deeply burried
support code, never in "normal" code.
> I actually also have a question about:
>
> #define BOOST_NO_WREGEX 1
>
> which causes problem
Bo Peng wrote:
So are we going to use MAX_PATH everywhere? Or just for windows?
Just for Windows. The only error is in get_temp_dir.
I actually also have a question about:
#define BOOST_NO_WREGEX 1
which causes problem for msvc. I now remove it for linux, and lyx
compiles fine. Why do we de
===
--- src/frontends/qt2/QContentPane.h (revision 14695)
+++ src/frontends/qt2/QContentPane.h (working copy)
@@ -16,6 +16,8 @@
#undef emit
#endif
+#include
+
This should go to QContentPane.C, not .h
I see.
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> On 8/15/06, Bo Peng <[EMAIL PROTECTED]> wrote:
>> > I'm using the boost included with LyX 1.4svn. Does 1.4 support
>> boost 1.33.1?
>>
>> generated for trunk before and I will see if that patch more or
>> less works for the branch.
Bo> Hi, JM
Joost Verburg <[EMAIL PROTECTED]> writes:
>
> > Index: src/support/package.C.in
> > ===
> > --- src/support/package.C.in(revision 14695)
> > +++ src/support/package.C.in(working copy)
> > -44,6 +44,10
> > #
Joost Verburg wrote:
> I'm using the boost included with LyX 1.4svn. Does 1.4 support boost
> 1.33.1?
No. 1.4 supports only the included boost.
Georg
Index: src/support/package.C.in
===
--- src/support/package.C.in(revision 14695)
+++ src/support/package.C.in(working copy)
@@ -44,6 +44,10 @@
# include // FSFindFolder, FSRefMakePath
#endif
+#ifndef PATH_MAX
+# define P
On 8/15/06, Bo Peng <[EMAIL PROTECTED]> wrote:
> I'm using the boost included with LyX 1.4svn. Does 1.4 support boost 1.33.1?
generated for trunk before and I will see if that patch more
or less works for the branch.
Hi, JMarc,
Attached patch is required to compile lyx1.4.x with msvc/scons. C
I'm using the boost included with LyX 1.4svn. Does 1.4 support boost 1.33.1?
OK. I will try to compile qt3 and see if I get the same errors. As a
matter of facts, lyx1.4.x will most likely not work with msvc. A msvc
patch was generated for trunk before and I will see if that patch more
or less w
Bo Peng wrote:
Did someone succeed to compile LyX 1.4svn with MSVC 2005? I keep getting
compile errors in boost\libs\regex\src\w32_regex_traits.cpp:
I did not try that, but are you using boost 1.32 (instead of 1.33.1)?
I'm using the boost included with LyX 1.4svn. Does 1.4 support boost 1.33.
Did someone succeed to compile LyX 1.4svn with MSVC 2005? I keep getting
compile errors in boost\libs\regex\src\w32_regex_traits.cpp:
I did not try that, but are you using boost 1.32 (instead of 1.33.1)?
Bo
75 matches
Mail list logo
