There is another issue I noticed:
Even if I just have compiled LyX and thus all libs are upt to date, the
po-files are recreated. This
is unnecessary because nothing has been changed. Is it possible to check also
for the po files if
something was changed and compile only then?
Same here, I'
On 05.12.2011 22:19, Uwe Stöhr wrote:
Am 05.12.2011 13:36, schrieb Vincent van Ravesteijn:
1 Warning(s)
This seems not harmful. This is just a warning that tells you that
static_mutex.cpp is sort of empty
because BOOST_HAS_THREADS is not defined. This shouldn't also be related to
CMake.
Is
Am 05.12.2011 13:36, schrieb Vincent van Ravesteijn:
1 Warning(s)
This seems not harmful. This is just a warning that tells you that
static_mutex.cpp is sort of empty
because BOOST_HAS_THREADS is not defined. This shouldn't also be related to
CMake.
Is it a real problem for you ?
No, I on
Am 05.12.2011 21:10, schrieb Peter Kümmel:
LYX_INSTALL overwrites LYX_CONSOLE:
But I don't use INSTALL, I use this:
-DLYX_MERGE_FILES=0 -DLYX_NLS=1 -DLYX_RELEASE=0 -DLYX_CONSOLE=ON
But I've added added a way to overwrite this:
-DLYX_CONSOLE=FORCE
This works, many thanks.
regards Uwe
Am 05.12.2011 12:41, schrieb Vincent van Ravesteijn:
Not so long ago, you were asking how to hide the console ? Now you're asking
how to get the console ?
Correct. For the release build used for the installer the console should be hidden. For developing
LyX the console is helpful.
regards
On 05.12.2011 02:11, Uwe Stöhr wrote:
Am 05.12.2011 02:05, schrieb Uwe Stöhr:
I have still some problems with CMake:
Problem 4:
I want to compile the lyx.exe in devel mode with its console (to e.g. see
shortcut conflicts).
I therefore compile with the compiler option
-DLYX_CONSOLE=ON
But
On 28.11.2011 01:54, Uwe Stöhr wrote:
Am 28.11.2011 01:50, schrieb Uwe Stöhr:
After some fiddling I got it to compile.
There is one warning when compiling the po-files:
CUSTOMBUILD : cygwin warning :
[D:\LyXSVN\lyx-devel\compile-result\po\translations.vcxproj]
MS-DOS style path detec
Op 5-12-2011 2:05, Uwe Stöhr schreef:
I have still some problems with CMake:
Problem 1:
When compiling LyX from scratch I get this warning:
"D:\LyXSVN\lyx-devel\compile-result\lyx.sln" (LyX;tex2lyx target) (1) ->
"D:\LyXSVN\lyx-devel\compile-result\src\LyX.vcxproj.metaproj" (default
target)
Op 5-12-2011 2:11, Uwe Stöhr schreef:
Am 05.12.2011 02:05, schrieb Uwe Stöhr:
I have still some problems with CMake:
Problem 4:
I want to compile the lyx.exe in devel mode with its console (to e.g.
see shortcut conflicts).
I therefore compile with the compiler option
-DLYX_CONSOLE=ON
But
Am Montag, 5. Dezember 2011 um 02:06:47, schrieb Uwe Stöhr
> Am 29.11.2011 10:27, schrieb Kornel Benko:
>
> > In cmake build ...
> > The po-files are recreated only if there are changes in some relevant
> > source. But
> > it is difficult to see, if changes are relevant for the po-files before
>
Am Montag, 5. Dezember 2011 um 02:05:05, schrieb Uwe Stöhr
> I have still some problems with CMake:
>
> Problem 1:
>
> When compiling LyX from scratch I get this warning:
>
> "D:\LyXSVN\lyx-devel\compile-result\lyx.sln" (LyX;tex2lyx target) (1) ->
> "D:\LyXSVN\lyx-devel\compile-result\src\LyX.vcxp
Am 05.12.2011 02:05, schrieb Uwe Stöhr:
I have still some problems with CMake:
Problem 4:
I want to compile the lyx.exe in devel mode with its console (to e.g. see
shortcut conflicts).
I therefore compile with the compiler option
-DLYX_CONSOLE=ON
But the result is still a lyx.exe without a
Am 29.11.2011 10:27, schrieb Kornel Benko:
In cmake build ...
The po-files are recreated only if there are changes in some relevant source.
But
it is difficult to see, if changes are relevant for the po-files before
actually creating them.
OK, but the po files are also created if I change no
I have still some problems with CMake:
Problem 1:
When compiling LyX from scratch I get this warning:
"D:\LyXSVN\lyx-devel\compile-result\lyx.sln" (LyX;tex2lyx target) (1) ->
"D:\LyXSVN\lyx-devel\compile-result\src\LyX.vcxproj.metaproj" (default target)
(2) ->
"D:\LyXSVN\lyx-devel\compile-resul
Am Dienstag, 29. November 2011 um 00:50:24, schrieb Uwe Stöhr
> Am 28.11.2011 12:50, schrieb Peter Kuemmel:
>
> > Good, you found a solution! Batch scripting seems really ugly indeed
>
> I made the script now compilable in trunk (There must not be a linebreak
> after an "else".) and added
> a sec
Am 28.11.2011 12:50, schrieb Peter Kuemmel:
Good, you found a solution! Batch scripting seems really ugly indeed
I made the script now compilable in trunk (There must not be a linebreak after an "else".) and added
a securtiy "" pair.
There is another issue I noticed:
Even if I just have co
Am 28.11.2011 12:58, schrieb Vincent van Ravesteijn:
Yes, I raised this issue before and joost fixed this IIRC at that time.
How? Do you have a recipe? I would like to fix it in our build script too.
This warning is not really important though.
I know, but it is a bit annoying that the co
Op 28 nov. 2011 12:49 schreef "Peter Kuemmel" het
volgende:
>
>
> Original-Nachricht
> > Datum: Mon, 28 Nov 2011 01:54:21 +0100
> > Von: "Uwe Stöhr"
> > An:
> > CC: "Peter Kümmel" , LyX-Devel <
lyx-devel@
Original-Nachricht
> Datum: Mon, 28 Nov 2011 02:27:09 +0100
> Von: "Uwe Stöhr"
> An:
> CC: "Peter Kümmel" , LyX-Devel
> Betreff: Re: CMake problems was: removing scons
> Am 28.11.2011 01:50, schrieb Uwe Stöhr:
>
> > I will r
Original-Nachricht
> Datum: Mon, 28 Nov 2011 01:50:27 +0100
> Von: "Uwe Stöhr"
> An: "Peter Kümmel"
> CC: LyX-Devel
> Betreff: Re: CMake problems was: removing scons
> Am 14.11.2011 09:30, schrieb Peter Kümmel:
>
> >>>
Original-Nachricht
> Datum: Mon, 28 Nov 2011 01:54:21 +0100
> Von: "Uwe Stöhr"
> An:
> CC: "Peter Kümmel" , LyX-Devel
> Betreff: Re: CMake problems was: removing scons
> Am 28.11.2011 01:50, schrieb Uwe Stöhr:
>
> > After some
Am 14.11.2011 09:30, schrieb Peter Kümmel:
Can anybody help me please?
Somehow reusing PATH does not work: set PATH=%GNUWIN32_DIR%\bin;%PATH%
This command works, also in an if statement, but for an unknown reason not inside an else part of an
if-statement.
But this has nothing to do with
On 14.11.2011 08:58, Peter Kümmel wrote:
On 13.11.2011 21:21, Uwe Stöhr wrote:
Today I took the time and restarted from scratch, meaning to set up a clean new
build system.
I followed the instructions bit by bit but CMake does not compile. In contrary
to my old system it
even didn't start a co
On 13.11.2011 21:21, Uwe Stöhr wrote:
Today I took the time and restarted from scratch, meaning to set up a clean new
build system.
I followed the instructions bit by bit but CMake does not compile. In contrary
to my old system it
even didn't start a compilation.
I fail to execute the build.ba
Today I took the time and restarted from scratch, meaning to set up a clean new
build system.
I followed the instructions bit by bit but CMake does not compile. In contrary to my old system it
even didn't start a compilation.
I fail to execute the build.bat script. Windows stops at this constr
Peter Kümmel wrote:
I hope it works now.
Yes it seems the error messages are gone thanks. But I guess you
misunderstood me. The solution was building fine but I didn't know to
which extent these error messages are harmful.
Thanks,
Abdel.
I hope it works now.
Peter
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Asger Ottar Alstrup wrote:
>>> Hi,
>>>
>>> Two things:
>>>
>>> - ENABLE_ASSERTIONS is not defined in config.h.
>>> #define ENABLE_ASSERTIONS 1
>>>
>>> - InsetMathMBox.C is compiled, although it should not be. Looking a
Peter Kümmel wrote:
Asger Ottar Alstrup wrote:
Hi,
Two things:
- ENABLE_ASSERTIONS is not defined in config.h.
#define ENABLE_ASSERTIONS 1
- InsetMathMBox.C is compiled, although it should not be. Looking at
development\cmake\src\mathed\CMakeLists.txt, it seems that the casing is
wrong - th
Asger Ottar Alstrup wrote:
> Hi,
>
> Two things:
>
> - ENABLE_ASSERTIONS is not defined in config.h.
> #define ENABLE_ASSERTIONS 1
>
> - InsetMathMBox.C is compiled, although it should not be. Looking at
> development\cmake\src\mathed\CMakeLists.txt, it seems that the casing is
> wrong - the B
Hi,
Two things:
- ENABLE_ASSERTIONS is not defined in config.h.
#define ENABLE_ASSERTIONS 1
- InsetMathMBox.C is compiled, although it should not be. Looking at
development\cmake\src\mathed\CMakeLists.txt, it seems that the casing is
wrong - the B is small. Don't know if that is the reason.
30 matches
Mail list logo