Le 04/07/2016 à 23:47, Guillaume Munch a écrit :
But doing so I noticed the following warning with clang, in case someone
fancies fixing it:
In file included from ../../src/EnchantChecker.cpp:14:
/usr/include/enchant/enchant++.h:55:25: warning:
'enchant::Exception::what' hides
overloaded v
Le 05/07/2016 00:55, Stephan Witt a écrit :
The enchant C++ header has more serious errors than this one.
Look at the method is_added …
I’m really surprised it’s so common on Linux.
Sorry, I missed the fact that it is not in the LyX source tree.
> Am 04.07.2016 um 23:47 schrieb Guillaume Munch :
>
> I tried to reproduce the compilation issues from today by compiling with
> clang, and also by changing the build type. The result is that I cannot
> reproduce the issues. Therefore, I am not going to be able adjust my
> build setup to make su
Am 18. Januar 2016 09:17:01 MEZ, schrieb "Uwe Stöhr" :
>
>
>From: Peter Kümmel
>
>Sent: Montag, 18. Januar 2016 03:18
>
>
>> Something is different on your system, there should be no problem
>with finding Qt 5. How actual is your cmake installation?
>
>
>Up to date (3.4.1). Qt is in the folder yo
Am 18. Januar 2016 01:10:41 MEZ, schrieb "Uwe Stöhr" :
>Am 17.01.2016 um 18:59 schrieb Peter Kümmel:
>
> > as you told, you have big problems in settings up clean build.
>> Therefore I've changed the build5-2010.bat file you added for
>building
>> with MSVC2010.
>
>As I reported proudly I was able
>
>I miss in your script a method to select to build a devel or an install
We need a reliable script for the installer input, which only builds lyx
nothing else, this is the intention. No parameters no choice.
>Moreover
>-DLYX_MERGE_REBUILD=1
This flag is only needed when you rebuild again,
Am 18. Januar 2016 01:10:41 MEZ, schrieb "Uwe Stöhr" :
>Am 17.01.2016 um 18:59 schrieb Peter Kümmel:
>
> > as you told, you have big problems in settings up clean build.
>> Therefore I've changed the build5-2010.bat file you added for
>building
>> with MSVC2010.
>
>As I reported proudly I was able
Am 17.01.2016 um 18:59 schrieb Peter Kümmel:
> as you told, you have big problems in settings up clean build.
Therefore I've changed the build5-2010.bat file you added for building
with MSVC2010.
As I reported proudly I was able to get a clean build. I still have some
troubles with CMake and
Hello Uwe,
as you told, you have big problems in settings up clean build.
Therefore I've changed the build5-2010.bat file you added for building
with MSVC2010.
This script now works with a double click, and builds LyX with MSVC2010
in a clean build directory.
Three pathes are hardcoded:
- Q
Am 14.01.2016 um 20:58 schrieb Georg Baum:
Please continue. I will have to switch to MinGW because Qt 5.6 does not
support MSVC 2010 and due to a bug in our code MSVC 2012, 2013 and 2015
cannot be used to compile LyX.
Do you mean http://www.lyx.org/trac/ticket/9892 or are there other bugs?
I
Uwe Stöhr wrote:
> Please continue. I will have to switch to MinGW because Qt 5.6 does not
> support MSVC 2010 and due to a bug in our code MSVC 2012, 2013 and 2015
> cannot be used to compile LyX.
Do you mean http://www.lyx.org/trac/ticket/9892 or are there other bugs?
Georg
Am 13.01.2016 um 05:41 schrieb Peter Kümmel:
If 5.6 is to buggy, we can also use 5.5.1 build with mingw.
Apparently beta1 will be built with Qt 5.5.1. And now, after some hours
of fiddling with CMake I am able to build Qt 5.5.1 with MSVC 2010 and
the result looks promising - stable LyX witho
Am 13. Januar 2016 05:27:22 MEZ, schrieb "Peter Kümmel" :
>Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel"
>:
>>
It is a warning only committed from me today to fix a linker error.
>>>You tried it with msvc 2010? And it worked?
>>>
>>>Yes. I can now compile with MSVC 2010 and Qt 5.5.1.
Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel" :
>
>>> It is a warning only committed from me today to fix a linker error.
>>You tried it with msvc 2010? And it worked?
>>
>>Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation of
>
>>Zlib and friends works here also with MSV
Am 13.01.2016 um 01:38 schrieb Peter Kümmel:
It is a warning only committed from me today to fix a linker error. You tried
it with msvc 2010? And it worked?
Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation of
Zlib and friends works here also with MSVC2013.
regards Uwe
Am 13. Januar 2016 01:18:12 MEZ, schrieb "Uwe Stöhr" :
>Am 12.01.2016 um 11:16 schrieb Peter Kümmel:
>
>> Yes, no Dlls any more (only the Qt related ones).
>
>OK.
>
>However I get now man times this warning:
>
>D:\LyXGit\Master\compile-2010\zconf.h(10): warning C4005: 'Z_PREFIX':
>Makro-Neudefinit
Am 12.01.2016 um 11:16 schrieb Peter Kümmel:
Yes, no Dlls any more (only the Qt related ones).
OK.
However I get now man times this warning:
D:\LyXGit\Master\compile-2010\zconf.h(10): warning C4005: 'Z_PREFIX':
Makro-Neudefinition [D:\LyXGit\Master\compile-2010\src\LyX.vcxproj]
D:
Am 12. Januar 2016 20:24:38 MEZ, schrieb Georg Baum
:
>Am 12.01.2016 um 00:37 schrieb Uwe Stöhr:
>> I did this now as I wrote in the
>> Questions for Uwe once you are back
>> thread.
>> I had to delete CMake's cache first and re-run it from scratch. The
>> 3rd party programs are compiled (with 13
Am 12.01.2016 um 00:37 schrieb Uwe Stöhr:
I did this now as I wrote in the
Questions for Uwe once you are back
thread.
I had to delete CMake's cache first and re-run it from scratch. The
3rd party programs are compiled (with 134 warnings) but I don't get a
DLL. Is this the plan - not to rely an
Am 12.01.2016 um 00:37 schrieb Uwe Stöhr:
I had to delete CMake's cache first and re-run it from scratch. The 3rd
party programs are compiled (with 134 warnings) but I don't get a DLL.
Is this the plan - not to rely anymore on DLLs?
Yes, no Dlls any more (only the Qt related ones).
thanks
Am 11.01.2016 um 20:44 schrieb Georg Baum:
welcome back and a happy new year!
Thanks. The same to you.
As I wrote in the "questions" mail: I am pretty sure that using the sources
in 3rdparty instead of the precompiled binary dependencies will result in a
better build and less work. Please tr
Hi Uwe,
welcome back and a happy new year!
Uwe Stöhr wrote:
> I can compile LyX 2.2dev with
> - Qt 4.8.7 and MSVC 2010
> - Qt 5.5.1 and MSVC 2013 (the resulting build has problems I already
> reported in December, but the compilation itself works)
>
> But if I use
> - Qt 5.5.1 and MSVC 2010
>
> Possible :-/ How can I convert it to the 4.2 format using the 4.3 designer?
afaik not possible.
either downgrade to 4.2 or upgrade to 4.4 or install them locally and use
only their designer.
pavel
Stefan Schimanski wrote:
> Possible :-/ How can I convert it to the 4.2 format using the 4.3
> designer?
You have to use the 4.2 designer.
Jürgen
Possible :-/ How can I convert it to the 4.2 format using the 4.3
designer?
Stefan
Am 10.03.2008 um 17:04 schrieb Jean-Marc Lasgouttes:
I get the following. Is the UI file in qt 4.3 format?
JMarc
g++ -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt4 -
I../../../src -DQT_CLEAN
On Sat, 2007-11-03 at 23:25 +0100, Abdelrazak Younes wrote:
> Please try again with latest rev.
>
> Abdel.
>
> PS: Sorry Juergen I didn't wait but this is an urgency.
Fixed.
Have fun,
Darren
Abdelrazak Younes wrote:
> Please try again with latest rev.
>
> Abdel.
>
> PS: Sorry Juergen I didn't wait but this is an urgency.
Thanks. I really have no explanation why this happened.
Jürgen
Am Sonntag 04 November 2007 schrieb Dov Feldstern:
> Works for me, thanks Abdel!
Here too. Thanx Abdel :)
> > Abdel.
> >
> > PS: Sorry Juergen I didn't wait but this is an urgency.
!!
Kornel
--
Kornel Benko
[EMAIL PROTECTED]
pgpsmKgeJPvzd.pgp
Description: PGP signature
Abdelrazak Younes wrote:
Kornel Benko wrote:
Am Samstag 03 November 2007 schrieb Dov Feldstern:
Dov Feldstern wrote:
Hi!
I'm also having compilation trouble in both trunk and branch. I'm using
Qt 4.2.1 (which is the version that debian etch offers as far as I can
tell).
Sorry, trunk is OK (I
Kornel Benko wrote:
Am Samstag 03 November 2007 schrieb Dov Feldstern:
Dov Feldstern wrote:
Hi!
I'm also having compilation trouble in both trunk and branch. I'm using
Qt 4.2.1 (which is the version that debian etch offers as far as I can
tell).
Sorry, trunk is OK (I hadn't updated); branch s
Am Samstag 03 November 2007 schrieb Dov Feldstern:
> Dov Feldstern wrote:
> > Hi!
> >
> > I'm also having compilation trouble in both trunk and branch. I'm using
> > Qt 4.2.1 (which is the version that debian etch offers as far as I can
> > tell).
>
> Sorry, trunk is OK (I hadn't updated); branch s
Dov Feldstern wrote:
Hi!
I'm also having compilation trouble in both trunk and branch. I'm using
Qt 4.2.1 (which is the version that debian etch offers as far as I can
tell).
Sorry, trunk is OK (I hadn't updated); branch still problematic, though.
* branch:
g++ -DHAVE_CONFIG_H -I. -I. -I
Thank you very much! I'll try.
Angus Leeming wrote:
Kostantino wrote:
Hi guys.
I tried to compile lyx-1.3.6 for my Slackware 10.1.
Configure runs fine with the options:
g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src
-I../../../src/frontends -I../../../images -I./qt2
-I/usr/l
> "Kostantino" == Kostantino <[EMAIL PROTECTED]> writes:
Kostantino> Hi guys. I tried to compile lyx-1.3.6 for my Slackware
Kostantino> 10.1.
Yes, this is unfortunate. I alreday fixed it in cvs, but you can
follow Georg Baum's advice here:
http://www.mail-archive.com/lyx-users@lists.lyx.org
Kostantino wrote:
Hi guys.
I tried to compile lyx-1.3.6 for my Slackware 10.1.
Configure runs fine with the options:
g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src
-I../../../src/frontends -I../../../images -I./qt2 -I/usr/lib/qt/include
-I../../../boost -I../../../src/frontends/con
On Wed, Jun 18, 2003 at 01:05:16PM +0200, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | I get the following with gcc 2.95.2 and gcc 2.96:
> [...]
> |
> | What can this be?
>
> Antiquated compilers with antiquated std libs.
Short of requiring gcc-3, what is
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| I get the following with gcc 2.95.2 and gcc 2.96:
[...]
|
| What can this be?
Antiquated compilers with antiquated std libs.
--
Lgb
Jules Bean <[EMAIL PROTECTED]> writes:
| Did you mean '...in only one function'?
Yes.
| I'm talking about having a simple using declaration for types referenced
| in this file. I can't see that that's unacceptable.
I am very fond of the idea of keeping the global namespace as clean as
possibl
On 3 Feb 2000, Lars Gullik Bjønnes wrote:
>
> | I'm talking about having a simple using declaration for types referenced
> | in this file. I can't see that that's unacceptable.
>
> I am very fond of the idea of keeping the global namespace as clean as
> possible, I realize that with current co
On 3 Feb 2000, Lars Gullik Bjønnes wrote:
> Jules Bean <[EMAIL PROTECTED]> writes:
>
> | Surely it's perfectly acceptable to have
> |
> | using std::vector;
> |
> | at the top of a file (in filescope).
>
> Not if you use that vector in only one file.
Did you mean '...in only one function'?
Jules Bean <[EMAIL PROTECTED]> writes:
| Surely it's perfectly acceptable to have
|
| using std::vector;
|
| at the top of a file (in filescope).
Not if you use that vector in only one file.
| That simply says 'in this file, I wish to introduce the type 'std::vector'
| into my namespace'. Th
On 28 Jan 2000, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> |
> | Lars> mmm...I want to do that...but so far I have not dared.
> | Lars> Eventually "using" should not be used in headers at
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> mmm...I want to do that...but so far I have not dared.
| Lars> Eventually "using" should not be used in headers at all, and as
| Lars> little as possible in filescope.
|
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> mmm...I want to do that...but so far I have not dared.
Lars> Eventually "using" should not be used in headers at all, and as
Lars> little as possible in filescope.
You mean we'll be forced to add std:: in front of all STL iden
Dekel Tsur <[EMAIL PROTECTED]> writes:
| What I meant was that instead of
|using std::copy;
|using std::ostream_iterator;
|copy(files.begin(), files.end(),
|ostream_iterator(ofs, "\n"));
|
| you can write
|std::copy(files.begin(), files.end(),
|std::
On Wed, Jan 26, 2000 at 11:39:53AM +0100, Jean-Marc Lasgouttes wrote:
> > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
>
> Dekel> I can't compile the latest cvs because of the using declaration
> Dekel> in lastfiles.C:85 and table.C:746 (I use an old g++ - ver.
> Dekel> 2.90.29) This can
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> I can't compile the latest cvs because of the using declaration
Dekel> in lastfiles.C:85 and table.C:746 (I use an old g++ - ver.
Dekel> 2.90.29) This can the fixed by moving the using declarations to
Dekel> the global scope, or stop
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Michael> I would like to have __GLIBCPP__ defined in about line 100
| Michael> and 120 (because the other code is not correct - says Sun CC
| Michael> 5.0)
|
| We should probably have a better code the this ad-hoc ifdef, anyway.
| Lars, could
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> a few suggestions for/from the Sun CC compiler:
Michael> src/insets/figinset.C, add
Michael>using std::flush;
Done.
Michael> src/support/lstrings.C,
Michael> I would like to have __GLIBCPP__ defined in about line 1
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> SUN CC complains about a few more problems in the lyx-devel
Michael> code dated Thu Jan 6 20:11:07 MET 2000. Please find a summary
Michael> of necessary fixes below.
Michael> Michael
Michael> lyx_lex.h, line 16, add
Michae
51 matches
Mail list logo
