Am Freitag, 8. Oktober 2010 schrieb Stephan Witt:
> Am 08.10.2010 um 08:53 schrieb Kornel Benko:
>
> > Am Freitag, 8. Oktober 2010 schrieb Stephan Witt:
> >> Am 07.10.2010 um 14:42 schrieb Kornel Benko:
> >>
> >>> Am Dienstag 05 Oktober 2010 schrieb Stephan Witt:
> Fine. And you don't know h
Am 08.10.2010 um 08:53 schrieb Kornel Benko:
> Am Freitag, 8. Oktober 2010 schrieb Stephan Witt:
>> Am 07.10.2010 um 14:42 schrieb Kornel Benko:
>>
>>> Am Dienstag 05 Oktober 2010 schrieb Stephan Witt:
Fine. And you don't know how it got generated?
>>
>> It works here in the same way as bef
Am Freitag, 8. Oktober 2010 schrieb Stephan Witt:
> Am 07.10.2010 um 14:42 schrieb Kornel Benko:
>
> > Am Dienstag 05 Oktober 2010 schrieb Stephan Witt:
> >> Fine. And you don't know how it got generated?
> >
> > The following does not harm here. And both
> > 1.) cmake on a used build-dir
> >
Am 07.10.2010 um 14:42 schrieb Kornel Benko:
> Am Dienstag 05 Oktober 2010 schrieb Stephan Witt:
>> Fine. And you don't know how it got generated?
>
> The following does not harm here. And both
> 1.) cmake on a used build-dir
> 2.) cmake on a fresh build-dir
> created Makefiles on lin
Am Dienstag 05 Oktober 2010 schrieb Stephan Witt:
> Fine. And you don't know how it got generated?
The following does not harm here. And both
1.) cmake on a used build-dir
2.) cmake on a fresh build-dir
created Makefiles on linux so, that the compile goes ok on the first run.
To q
Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
> The 2nd build fails. But it should have failed on the 1st run too.
>
Stephan, I did not find anything fundamentally wrong. Only one idea:
We could mark the moc-files as generated. But since they are already all
explicitly mentioned in "OUTPUT" o
Am Dienstag 05 Oktober 2010 schrieb Stephan Witt:
> Fine. And you don't know how it got generated?
Sorry no, only when. I, too, have to study the
./src/frontends/qt4/CMakeLists.txt first.
Kornel
signature.asc
Description: This is a digitally signed message part.
Am 05.10.2010 um 19:00 schrieb Kornel Benko:
> Am Dienstag 05 Oktober 2010 schrieb Stephan Witt:
>> Am 05.10.2010 um 11:55 schrieb Kornel Benko:
>>> Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
The 2nd build fails. But it should have failed on the 1st run too.
>>>
>>> Not on linux. Her
Am Dienstag 05 Oktober 2010 schrieb Stephan Witt:
> Am 05.10.2010 um 11:55 schrieb Kornel Benko:
> > Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
> >> The 2nd build fails. But it should have failed on the 1st run too.
> >
> > Not on linux. Here it fails in 1st run of make.
>
> Of course. I
Am 05.10.2010 um 11:55 schrieb Kornel Benko:
> Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
>> The 2nd build fails. But it should have failed on the 1st run too.
>>
> Not on linux. Here it fails in 1st run of make.
Of course. I could guess it from your first message already.
But the mechan
Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
> The 2nd build fails. But it should have failed on the 1st run too.
>
Not on linux. Here it fails in 1st run of make.
Kornel
signature.asc
Description: This is a digitally signed message part.
Am 05.10.2010 um 10:51 schrieb Kornel Benko:
> Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
>> Am 05.10.2010 um 09:18 schrieb Kornel Benko:
>>
>>> Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
Dear CMake gurus,
I'm having serious problems with my cmake generated Xcode-
Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
> Am 05.10.2010 um 09:18 schrieb Kornel Benko:
>
> > Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
> >> Dear CMake gurus,
> >>
> >> I'm having serious problems with my cmake generated Xcode-project for LyX.
> >>
> >> 1. If I change some .ui
Am 05.10.2010 um 09:18 schrieb Kornel Benko:
> Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
>> Dear CMake gurus,
>>
>> I'm having serious problems with my cmake generated Xcode-project for LyX.
>>
>> 1. If I change some .ui file I have to compile the project twice to get
>> the changes to
Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
> Dear CMake gurus,
>
> I'm having serious problems with my cmake generated Xcode-project for LyX.
>
> 1. If I change some .ui file I have to compile the project twice to get
> the changes to work. The first build run seems to compile the .ui fi
Am Dienstag, 5. Oktober 2010 schrieb Stephan Witt:
> Dear CMake gurus,
>
> I'm having serious problems with my cmake generated Xcode-project for LyX.
>
> 1. If I change some .ui file I have to compile the project twice to get
> the changes to work. The first build run seems to compile the .ui fi
Dear CMake gurus,
I'm having serious problems with my cmake generated Xcode-project for LyX.
1. If I change some .ui file I have to compile the project twice to get
the changes to work. The first build run seems to compile the .ui file
too late. The 2nd run finally compiles the generated source
Please ignore this. I forgot to run cmake...
Abdelrazak Younes wrote:
Hi,
Is this variable new?
4>..\..\..\trunk\src\support\Package.cpp(465) : error C2065:
'LYX_DIR_VER' : identificateur non déclaré
4>..\..\..\trunk\src\support\Package.cpp(468) : error C2065:
'LYX_DIR_VER' : identificateur
Hi,
Is this variable new?
4>..\..\..\trunk\src\support\Package.cpp(465) : error C2065:
'LYX_DIR_VER' : identificateur non déclaré
4>..\..\..\trunk\src\support\Package.cpp(468) : error C2065:
'LYX_DIR_VER' : identificateur non déclaré
4>..\..\..\trunk\src\support\Package.cpp(559) : error C2146:
Andre Poenitz wrote:
On Tue, Sep 04, 2007 at 09:09:12PM +0200, Peter Kümmel wrote:
Abdelrazak Younes wrote:
Andre',
I think your recent cleanups is causing some problem on Windows. The
different projects seems to be regenerated at each recompilation. And I
get too much recompile too, especia
On Tue, Sep 04, 2007 at 09:09:12PM +0200, Peter Kümmel wrote:
> Abdelrazak Younes wrote:
> >Andre',
> >
> >I think your recent cleanups is causing some problem on Windows. The
> >different projects seems to be regenerated at each recompilation. And I
> >get too much recompile too, especially for
Abdelrazak Younes wrote:
Andre',
I think your recent cleanups is causing some problem on Windows. The
different projects seems to be regenerated at each recompilation. And I
get too much recompile too, especially for boost and intl.
Could you have a look please?
Abdel.
With set(CMAKE_SUPP
Abdelrazak Younes wrote:
I think your recent cleanups is causing some problem on Windows. The
different projects seems to be regenerated at each recompilation. And
I get too much recompile too, especially for boost and intl.
Let me add that (on Linux) despite
with options \"'--enable-stdlib-de
Andre',
I think your recent cleanups is causing some problem on Windows. The
different projects seems to be regenerated at each recompilation. And I
get too much recompile too, especially for boost and intl.
Could you have a look please?
Abdel.
> If you change all @VAR@ to $VAR$ or vise vesa, autotools may have to
> be changed as well, so ask Georg first. Scons handled both cases with
> a little bit work.
So IIUC there's nothing to do with Scons right?
Right now, scons can handle both % and @, I will remove one of them.
Bo
Bo Peng wrote:
> Additionally cmake needs @VAR@ instead of %VAR% to
> get VAR replaced with its value.
> Doesn't configure also work with @? Then please commit
> attached patch.
If you change all @VAR@ to $VAR$ or vise vesa, autotools may have to
be changed as well, so ask Georg first. Scons ha
Georg Baum wrote:
Am Donnerstag, 21. Dezember 2006 08:52 schrieb Peter Kümmel:
Bo Peng wrote:
Additionally cmake needs @VAR@ instead of %VAR% to
get VAR replaced with its value.
Doesn't configure also work with @? Then please commit
attached patch.
If you change all @VAR@ to $VAR$ or vise vesa
Am Donnerstag, 21. Dezember 2006 08:52 schrieb Peter Kümmel:
> Bo Peng wrote:
> >> > Additionally cmake needs @VAR@ instead of %VAR% to
> >> > get VAR replaced with its value.
> >> > Doesn't configure also work with @? Then please commit
> >> > attached patch.
> >
> > If you change all @VAR@ to $V
Bo Peng wrote:
>> > Additionally cmake needs @VAR@ instead of %VAR% to
>> > get VAR replaced with its value.
>> > Doesn't configure also work with @? Then please commit
>> > attached patch.
>
> If you change all @VAR@ to $VAR$ or vise vesa, autotools may have to
> be changed as well, so ask Georg
> Additionally cmake needs @VAR@ instead of %VAR% to
> get VAR replaced with its value.
> Doesn't configure also work with @? Then please commit
> attached patch.
If you change all @VAR@ to $VAR$ or vise vesa, autotools may have to
be changed as well, so ask Georg first. Scons handled both cases
Peter Kümmel wrote:
I've applied this patch:
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 16341)
+++ CMakeLists.txt (working copy)
@@ -83,6 +83,17 @@
endif(noconsole)
endif(WIN32)
+set(LYX_DIR "
Abdelrazak Younes wrote:
> Hi Peter,
>
> package.C contains the following:
>
> string const top_srcdir()
> {
> static string const dir("%TOP_SRCDIR%");
> return dir;
> }
>
>
> string const hardcoded_localedir()
> {
> return string("%LOCALEDIR%");
> }
>
>
> string const hardcoded_s
Hi Peter,
package.C contains the following:
string const top_srcdir()
{
static string const dir("%TOP_SRCDIR%");
return dir;
}
string const hardcoded_localedir()
{
return string("%LOCALEDIR%");
}
string const hardcoded_system_support_dir()
{
return string("%LY
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Peter Kümmel wrote:
Abdelrazak Younes wrote:
> I think this is something else as I remove CMakeCache.txt before
> trying.
The path to qt is hard coded it Joost's qmake:
D:\LyX\lyx-winPackage-msvc\q
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
I think this is something else as I remove CMakeCache.txt before trying.
The path to qt is hard coded it Joost's qmake:
D:\LyX\lyx-winPackage-msvc\qt-4\lib
Do you have Joost's qt at this place?
Now I h
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> I think this is something else as I remove CMakeCache.txt before trying.
>>
>> The path to qt is hard coded it Joost's qmake:
>> D:\LyX\lyx-winPackage-msvc\qt-4\lib
>>
>> Do you have Joost's qt at this place?
>
> Now I
Peter Kümmel wrote:
Abdelrazak Younes wrote:
I think this is something else as I remove CMakeCache.txt before trying.
The path to qt is hard coded it Joost's qmake:
D:\LyX\lyx-winPackage-msvc\qt-4\lib
Do you have Joost's qt at this place?
Now I have yes and it is correctly detected. But why
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Dear Joost, dear Peter,
>>>
>>> I wanted to try Qt4.2 but avoid it compilatation ao I tried lyx Joost's
>>> package (lyx-windows-deps-msvc-qt4.zip). I put the inner qt-4/bin in my
>>> PATH variable but I have a conflict
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Dear Joost, dear Peter,
I wanted to try Qt4.2 but avoid it compilatation ao I tried lyx Joost's
package (lyx-windows-deps-msvc-qt4.zip). I put the inner qt-4/bin in my
PATH variable but I have a conflict problem:
D:\devel\lyx\trunk\development\cmake
Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Abdelrazak Younes wrote:
>>> Dear Joost, dear Peter,
>>>
>>> I wanted to try Qt4.2 but avoid it compilatation ao I tried lyx
>>> Joost's package (lyx-windows-deps-msvc-qt4.zip). I put the inner
>>> qt-4/bin in my PATH variable but I have a conf
Abdelrazak Younes wrote:
> Dear Joost, dear Peter,
>
> I wanted to try Qt4.2 but avoid it compilatation ao I tried lyx Joost's
> package (lyx-windows-deps-msvc-qt4.zip). I put the inner qt-4/bin in my
> PATH variable but I have a conflict problem:
>
> D:\devel\lyx\trunk\development\cmake>cmake .
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Dear Joost, dear Peter,
I wanted to try Qt4.2 but avoid it compilatation ao I tried lyx
Joost's package (lyx-windows-deps-msvc-qt4.zip). I put the inner
qt-4/bin in my PATH variable but I have a conflict problem:
Another problem is this:
A
Abdelrazak Younes wrote:
Dear Joost, dear Peter,
I wanted to try Qt4.2 but avoid it compilatation ao I tried lyx Joost's
package (lyx-windows-deps-msvc-qt4.zip). I put the inner qt-4/bin in my
PATH variable but I have a conflict problem:
Another problem is this:
aspell header : D:/LyX/
Dear Joost, dear Peter,
I wanted to try Qt4.2 but avoid it compilatation ao I tried lyx Joost's
package (lyx-windows-deps-msvc-qt4.zip). I put the inner qt-4/bin in my
PATH variable but I have a conflict problem:
D:\devel\lyx\trunk\development\cmake>cmake . -Dnls=1
-DGNUWIN32_DIR=D:\devel\ly
44 matches
Mail list logo
