Von: "Kurt V. Hindenburg" <[EMAIL PROTECTED]>
> Hello,
> getting farther along... any ideas where to start?
>
> make[2]: Entering directory
> `/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake'
> Generating keramikrc.h
> cd /mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake/kstyles/k
Hello,
getting farther along... any ideas where to start?
make[2]: Entering directory
`/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake'
Generating keramikrc.h
cd /mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake/kstyles/keramik
&& ../../bin/genembed
--file
/mnt/part6/KDE/builds
On Wednesday 22 March 2006 12:48, Alexander Neundorf wrote:
| Is this a current checkout ?
| trunk or snapshot ?
| Did you set any RPATH related options ?
| LD_LIBRARY_PATH there is NOT required.
| You are on gentoo, right ?
cmake version 2.3-20060317
kdelibs4_snapshot, qt-copy from trunk/
yes, ge
Hi,
I have enough resources to do continuous builds and nightly builds here and
was wondering if there was an easy way to get that set up? I've read the wiki
and confess to being a bit confused.
Thanks
--
Matt
___
Kde-buildsystem mailing list
Kde-buil
Hi,
I'd like to start working on native CMake support for KDevelop 4. What I mean
by this is that when you open a project that is set up to use CMake, the
CMakeLists.txt files plus any additional cmake macros are automatically
loaded in and can be edited natively?
Does CMake have a library tha
David Faure wrote:
> On Thursday 16 March 2006 22:30, Alexander Neundorf wrote:
>>"none" - don't use RPATH at all
>>When installed, the libs have to be in the system library path
>>(ld.so.conf/LD_LIBRARY_PATH)
>>To run the executables during the build, simple wrapper shell scripts are
>>created w
On Thursday 16 March 2006 22:30, Alexander Neundorf wrote:
> "none" - don't use RPATH at all
> When installed, the libs have to be in the system library path
> (ld.so.conf/LD_LIBRARY_PATH)
> To run the executables during the build, simple wrapper shell scripts are
> created which set (DY)LD_LIBRA
At 05:46 PM 3/22/2006, Michael Biebl wrote:
>> > It's no problem to change it back, but no matter which option we choose,
>> > there
>> > will probably always be situations where the wrong one can be found.
>_
Actually, I think this is the problem:
[EMAIL PROTECTED]:~/Dashboards/My Tests/kdelibs
I would simply go with qmake and don't care for qmake-qt4, as it is
Debian specific.
If people don't specify Qt4 as default (i.e. create the qmake and
other symlinks) because they want to keep Qt3 around, they could still
use -DQT_QMAKE_EXECUTABLE=qmake-qt4
Just my 2¢
On 3/22/06, David Faure <[EM
On Wednesday 22 March 2006 23:31, Alexander Neundorf wrote:
> Somehow I think it is not possible to guess which one is the right one.
> If it would prefer qmake over qmake-qt4, other people might complain for
> which
> qmake points to qmake-qt3 whereas qmake-qt4 would have been the Qt4-one...
>
On Wednesday 22 March 2006 23:31, Alexander Neundorf wrote:
> > On Wednesday 22 March 2006 23:05, David Faure wrote:
> > > On Wednesday 22 March 2006 22:59, Matthias Kretz wrote:
> > > > On Wednesday 22 March 2006 20:05, Alexander Neundorf wrote:
> > > > > prefer moc-qt4, uic-qt4 and qmake-qt4 over
> On Wednesday 22 March 2006 23:05, David Faure wrote:
> > On Wednesday 22 March 2006 22:59, Matthias Kretz wrote:
> > > On Wednesday 22 March 2006 20:05, Alexander Neundorf wrote:
> > > > prefer moc-qt4, uic-qt4 and qmake-qt4 over moc, uic and qmake
> > >
> > > Why? My qt-copy doesn't create such
On Wednesday 22 March 2006 23:12, Ralf Habacker wrote:
> Are there any chances that qt-copy contains the gpl'ed windows (and the
> mac related) qt code ?
No; I don't think there is a released source version of Qt that has support for
all platforms.
--
David Faure, [EMAIL PROTECTED], sponsored
David Faure schrieb:
> On Wednesday 22 March 2006 19:32, Ralf Habacker wrote:
>
>> "This directory contains patches for Qt that haven't been accepted by
>> TrollTech
>> yet. All patches in this directory itself shouldn't make qt-copy incompatible
>> to official Qt, patches adding new API etc. b
On Wednesday 22 March 2006 19:32, Ralf Habacker wrote:
> "This directory contains patches for Qt that haven't been accepted by
> TrollTech
> yet. All patches in this directory itself shouldn't make qt-copy incompatible
> to official Qt, patches adding new API etc. belong to the notsafe/
> subdirec
Paulo Jorge Guedes schrieb:
>> -Original Message-
>> From: Ralf Habacker [mailto:[EMAIL PROTECTED]
>> Sent: quarta-feira, 22 de Março de 2006 18:33
>> To: kde-buildsystem@kde.org
>> Subject: Re: kdewin32 build error
>>
>> Ralf Habacker schrieb:
>>> I'm using qt 4.1.0 and had the same proble
At 02:07 PM 3/22/2006, you wrote:
>On Wednesday 22 March 2006 19:25, Michael Olbrich wrote:
>> On Wed, Mar 22, 2006 at 07:04:10PM +0100, Alexander Neundorf wrote:
>> > On Wednesday 22 March 2006 19:00, Michael Olbrich wrote:
>> > > I think that's part of the problem. What's the right(tm) way to ins
On Wednesday 22 March 2006 19:25, Michael Olbrich wrote:
> On Wed, Mar 22, 2006 at 07:04:10PM +0100, Alexander Neundorf wrote:
> > On Wednesday 22 March 2006 19:00, Michael Olbrich wrote:
> > > I think that's part of the problem. What's the right(tm) way to install
> > > qmake from qt3 and qt4? And
Am Dienstag, 21. März 2006 19:27 schrieb William A. Hoffman:
[...]
> My understanding was that QTDIR was being deprecated for qt4, and that
> qmake had to be in the PATH. I can not find a reference on the qt site,
> but there are several posts like this one floating around:
>
> http://lists.ibibli
> -Original Message-
> From: Ralf Habacker [mailto:[EMAIL PROTECTED]
> Sent: quarta-feira, 22 de Março de 2006 18:33
> To: kde-buildsystem@kde.org
> Subject: Re: kdewin32 build error
>
> Ralf Habacker schrieb:
> > I'm using qt 4.1.0 and had the same problem. This is because recent
> > kdeu
Ralf Habacker schrieb:
> Paulo Jorge Guedes schrieb:
>
>> And this other one on kdecore:
>>
>> In file included from d:/kde/kdelibs/kdeui/kaction.h:530,
>> from d:/kde/kdelibs/kdecore/../kdeui/kstdaction_p.h:25,
>> from d:/kde/kdelibs/kdecore/kacceleratormanager
Paulo Jorge Guedes schrieb:
> And this other one on kdecore:
>
> In file included from d:/kde/kdelibs/kdeui/kaction.h:530,
> from d:/kde/kdelibs/kdecore/../kdeui/kstdaction_p.h:25,
> from d:/kde/kdelibs/kdecore/kacceleratormanager.cpp:48:
> d:/kde/kdelibs/kdeui/kac
On Wed, Mar 22, 2006 at 07:04:10PM +0100, Alexander Neundorf wrote:
> On Wednesday 22 March 2006 19:00, Michael Olbrich wrote:
> > I think that's part of the problem. What's the right(tm) way to install
> > qmake from qt3 and qt4? And I mean distribution packages not a separate
> > hand compiled tr
On Wed, Mar 22, 2006 at 06:22:38PM +0100, Alexander Neundorf wrote:
> On Wednesday 22 March 2006 14:53, Thiago Macieira wrote:
> > Michael Olbrich wrote:
> > >Hmm, that will give me:
> > >QT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4
> > >QT_BINARY_DIR=/usr/bin
> > >QT_UIC_EXECUTABLE=/usr/bin/uic
> > >whi
On Wednesday 22 March 2006 19:00, Michael Olbrich wrote:
> On Wed, Mar 22, 2006 at 05:38:06PM +0100, Thiago Macieira wrote:
> > William A. Hoffman wrote:
> > >The current FindQT4.cmake in kde looks for qmake-qt4, then qmake.
> > >Is qmake-qt4 standard? When I build and install qt-copy, I only
> >
On Wed, Mar 22, 2006 at 05:38:06PM +0100, Thiago Macieira wrote:
> William A. Hoffman wrote:
> >The current FindQT4.cmake in kde looks for qmake-qt4, then qmake.
> >Is qmake-qt4 standard? When I build and install qt-copy, I only
> >get a qmake, however there is a qmake-qt4 on the machine that gets
On Wednesday 22 March 2006 17:49, Kurt V. Hindenburg wrote:
> I was getting these errors below; I fixed this by 'export
> $LD_LIBRARY_PATH=$QTDIR/lib'
>
> make[2]: Entering directory
> `/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake'
> Generating ksycoca_skel.cpp
> cd /mnt/part6/KDE/build
And this other one on kdecore:
In file included from d:/kde/kdelibs/kdeui/kaction.h:530,
from d:/kde/kdelibs/kdecore/../kdeui/kstdaction_p.h:25,
from d:/kde/kdelibs/kdecore/kacceleratormanager.cpp:48:
d:/kde/kdelibs/kdeui/kactionclasses.h:223: error: expected clas
Ok, after I'm through building kdelibs, I tried kdebase. Now after an
svn-clean & svn up. I get a similar error as yesterday with kdelibs:
-- Generating done
-- Build files have been written to: /data2/kde4/build/kdebase
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/media/extra/d
Alexander Neundorf wrote:
>> $ ls `qmake -query QT_INSTALL_BINS`/uic
>> /home/tjmaciei/troll/qt-4.1-build/bin/uic*
>>
>> $ ls `pkg-config --variable prefix QtCore`/bin/uic
>> /home/tjmaciei/troll/qt-4.1-build/bin/uic*
>
>Is it somewhere documented what can be queried ?
>I didn't find it yet.
No, t
On 3/22/06, Thiago Macieira <[EMAIL PROTECTED]> wrote:
> William A. Hoffman wrote:
> >The current FindQT4.cmake in kde looks for qmake-qt4, then qmake.
> >Is qmake-qt4 standard? When I build and install qt-copy, I only
> >get a qmake, however there is a qmake-qt4 on the machine that gets
> >found,
On Wednesday 22 March 2006 14:53, Thiago Macieira wrote:
> Michael Olbrich wrote:
> >On Tue, Mar 21, 2006 at 11:19:57PM +0100, Alexander Neundorf wrote:
> >> Hi,
> >>
> >> after the discussions today on the KDE and the cmake mailing lists, it
> >> seems that Qt4 obsoletes the use of QTDIR and inste
I'm having this error with mingw:
In file included from d:/kde/kdelibs/win/src/realpath.c:24:
d:/kde/kdelibs/win/include/mingw/unistd.h:137: error: conflicting types
for 'getopt'
d:/MinGW/bin/../lib/gcc/mingw32/3.4.4/../../../../include/getopt.h:47:
error: previous declaration of 'getopt' was here
Kurt V. Hindenburg wrote:
> I was getting these errors below; I fixed this by 'export
> $LD_LIBRARY_PATH=$QTDIR/lib'
>
> make[2]: Entering directory
> `/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake'
> Generating ksycoca_skel.cpp
> cd /mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_
At 11:38 AM 3/22/2006, Thiago Macieira wrote:
>William A. Hoffman wrote:
>>The current FindQT4.cmake in kde looks for qmake-qt4, then qmake.
>>Is qmake-qt4 standard? When I build and install qt-copy, I only
>>get a qmake, however there is a qmake-qt4 on the machine that gets
>>found, and is the wr
I was getting these errors below; I fixed this by 'export
$LD_LIBRARY_PATH=$QTDIR/lib'
make[2]: Entering directory
`/mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake'
Generating ksycoca_skel.cpp
cd /mnt/part6/KDE/builds/trunk/KDE/kdelibs4_snapshot_cmake/kdecore &&
LD_LIBRARY_PATH=/mnt/p
William A. Hoffman wrote:
>The current FindQT4.cmake in kde looks for qmake-qt4, then qmake.
>Is qmake-qt4 standard? When I build and install qt-copy, I only
>get a qmake, however there is a qmake-qt4 on the machine that gets
>found, and is the wrong version of qt4. So, what is qmake-qt4?
I've
qmake or qmake-qt4
The current FindQT4.cmake in kde looks for qmake-qt4, then qmake.
Is qmake-qt4 standard? When I build and install qt-copy, I only
get a qmake, however there is a qmake-qt4 on the machine that gets
found, and is the wrong version of qt4. So, what is qmake-qt4?
BTW, this is th
At 06:17 AM 3/22/2006, Thiago Macieira wrote:
>David Faure wrote:
>>For me it doesn't.
>
>I forgot to add:
>$ echo $PKG_CONFIG_PATH
>/home/tjmaciei/local/dbus/lib/pkgconfig:/home/tjmaciei/troll/qt-4.1-build/lib
>
>>$ qmake -query QT_INSTALL_HEADERS
>>/devel/kde/src/4/qt-copy/include
>
>This approac
Might be a good idea to say why cmake does not use the QTDIR and
KDEDIR variable anymore (because they are deprecated). So
people/developers will hopefully stop using it and not think that
cmake is broken or limited.
Michael
___
Kde-buildsystem mailing
Laurent Montel wrote:
> regexp into cmake is not standard.
> Where can I read doc about it ?
See comments in front of the regex class definition:
http://www.cmake.org/cgi-bin/viewcvs.cgi/Source/kwsys/RegularExpression.hxx.in?root=CMake&view=markup
Note that whenever you need a backslash in a reg
Now that the wiki is back...
FYI: I just updated http://wiki.kde.org/tiki-index.php?page=KDECMakeIntro
to say that $KDEDIR and $QTDIR are not supported by the KDE 4 cmake system.
I also updated a few other things in there, like where you can find the cmake
2.3.4 tarball.
..and some other minor
Michael Olbrich wrote:
>On Tue, Mar 21, 2006 at 11:19:57PM +0100, Alexander Neundorf wrote:
>> Hi,
>>
>> after the discussions today on the KDE and the cmake mailing lists, it
>> seems that Qt4 obsoletes the use of QTDIR and instead requires that
>> qmake is available via PATH.
>>
>> So I changed t
On Tuesday 21 March 2006 17:56, Allen Winter wrote:
> Howdy,
>
> In kdelibs/kio/kfile there is compile error in kfileiconview.moc
> ("removeToolTip was not declared in this scope").
> So I cd into that subdir, and look for removeToolTip, which is found only in
> kfileiconview.moc.
>
> Hmm.. so
On Tue, Mar 21, 2006 at 11:19:57PM +0100, Alexander Neundorf wrote:
> Hi,
>
> after the discussions today on the KDE and the cmake mailing lists, it seems
> that Qt4 obsoletes the use of QTDIR and instead requires that qmake is
> available via PATH.
>
> So I changed the detection of Qt4 accordi
David Faure wrote:
>For me it doesn't.
I forgot to add:
$ echo $PKG_CONFIG_PATH
/home/tjmaciei/local/dbus/lib/pkgconfig:/home/tjmaciei/troll/qt-4.1-build/lib
>$ qmake -query QT_INSTALL_HEADERS
>/devel/kde/src/4/qt-copy/include
This approach is problematic if you have both Qt3 and Qt4 support. Ho
On Wednesday 22 March 2006 10:24, Thiago Macieira wrote:
> David Faure wrote:
> >Apparently it's so that we can run things like
> >qmake -query QT_INSTALL_HEADERS
>
> $ qmake -query QT_INSTALL_HEADERS
> /home/tjmaciei/troll/qt-4.1-build/include
>
> $ pkg-config --variable includedir QtCore
> /hom
David Faure wrote:
>Apparently it's so that we can run things like
>qmake -query QT_INSTALL_HEADERS
$ qmake -query QT_INSTALL_HEADERS
/home/tjmaciei/troll/qt-4.1-build/include
$ pkg-config --variable includedir QtCore
/home/tjmaciei/troll/qt-4.1-build/include/QtCore
$ pkg-config --cflags QtCore
Hi,
regexp into cmake is not standard.
Where can I read doc about it ?
Regards
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
49 matches
Mail list logo
