I need to make the test for statfs try sys/mount.h, currently I get
the following when compiling kdecore:
---(snip!)---
/Users/ranger/cvs/kdelibs/kdecore/kmountpoint.cpp: In static member
function 'static QListKSharedPtrKMountPoint
KMountPoint::currentMountPoints(int)':
On 4/1/06, William A. Hoffman [EMAIL PROTECTED] wrote:
At 12:02 AM 4/1/2006, Benjamin Reed wrote:
I notice that my continuous build isn't running the tests. I just
copied and slightly modified the dash17 one, so if you have any ideas
on what I need to do to get tests working, please let me
I'm finding out none of the visibility exports are working right
because kdemacros.h is not getting installed, and thus my build ends
up finding my kdemacros.h from my fink-installed kde 3.5 (for X11).
Any idea what needs to be fixed in the build to install it?
On 4/3/06, Alexander Neundorf [EMAIL PROTECTED] wrote:
This works on my system and kdemacros.h is installed to /opt/kde4/include/
Can you please check why this doesn't happen on your system ?
hm, ok, I'll give it another try when I have the chance
On 4/4/06, Maarten Th. Mulders [EMAIL PROTECTED] wrote:
when building, kglobalaccel.h can't find kdeui/kglobalaccel_win.h.
Indeed, this file does not exist. KDE 3.4 has it, but it uses Qt3. How
to solve this problem?
I think cmake was scanning the dependencies of kglobalaccel.cpp and
thought
On 4/6/06, Alexander Neundorf [EMAIL PROTECTED] wrote:
Does the app-bundle work for you otherwise ?
for the most part; dcop's having some issues but I haven't figured out why yet.
It probably mixed up the kdesu library with the kdesu executable, since there
is a target named kdesu in the
On 4/7/06, Tanner Lovelace [EMAIL PROTECTED] wrote:
e.g. kdialog then ? With the full path to the binary inside the bundle ?
Yes, if you're running from the command line.
Right, there is already code in kdelibs to find bundles #ifdef
Q_WS_MAC so the only place there are issues is
On 4/11/06, Alexander Neundorf [EMAIL PROTECTED] wrote:
I was not able to write a shell script which forwards its arguments to a
program it calls:
#!/bin/sh
dcopidl2cpp $@
it should be dcopidl2cpp $@
It looks weird, but $@ will give you proper space-separated args.
ranger$ cat END
I've built kdelibs head, and I was trying to just make kdebase head
(since there's no bleedingedge, I'm assuming it still works against
kdelibs head?) and I get this error trying to cmake it:
---(snip!)---
Disco-Volante:~/cvs/build/kdebase ranger$ !cmake
cmake ../../kdebase
On 5/3/06, David Faure [EMAIL PROTECTED] wrote:
No, no. kdebase works against branches/work/kdelibs4_snapshot.
OK. I will have to go back and check, but I thought there were OSX
fixes that didn't make the last snapshot, but doing a diff, I see
that's not the case. I'll go build the snapshot
On 5/3/06, David Faure [EMAIL PROTECTED] wrote:
And what does kde-config --path data say?
Disco-Volante:~/cvs/build/kdebase ranger$ kde-config --path data
/Users/ranger/Library/Preferences/KDE/share/apps/:/sw/share/apps/:/opt/kde4/share/apps/
...so it looks like KDEDIRS is poisoning it.
I'm trying to build the qt4 dbus bindings as universal binaries. I
have to use the Xcode generator, it appears, or else CMake doesnt' do
anything with the archtecture environment variables.
It looks like we're either making some assumptions in our CMakeFiles,
or Xcode generation is broken,
for some reason, cmake 2.4.2 doesn't seem to be creating the
app-bundle directories before trying to link binaries:
---(snip!)---
Building CXX object
kdecore/kconfig_compiler/CMakeFiles/kconfig_compiler.dir/kconfig_compiler.o
Linking CXX executable
On 5/27/06, William A. Hoffman [EMAIL PROTECTED] wrote:
cmSystemTools::MakeDirectory(macdir.c_str());
Could you add a print statement in the above part of cmake, and
see what macdir is getting created? Maybe there is some issue
with the universal binaries.
Universal binaries shouldn't
On 5/27/06, William A. Hoffman [EMAIL PROTECTED] wrote:
Looking at the code, it should work The directory should be created
during the cmake run, long before make ever runs.
oh! I didn't really notice what you said when I first responded to
this thread. That would explain it.
I deleted
So it turns out that the DNSSD test was failing on OSX because there's
no -ldns_sd (which there shouldn't be, the DNS-SD stuff is direct in
libSystem/libc on OSX). Attached is a patch, not sure if there's a
better way to do this.
Now, though, I get an error trying to compile the dnssd portion of
On 5/29/06, Stephan Kulow [EMAIL PROTECTED] wrote:
Am Montag, 29. Mai 2006 05:49 schrieb Benjamin Reed:
So it turns out that the DNSSD test was failing on OSX because there's
no -ldns_sd (which there shouldn't be, the DNS-SD stuff is direct in
libSystem/libc on OSX). Attached is a patch
On 5/29/06, David Faure [EMAIL PROTECTED] wrote:
But kconfig_compiler is a NOGUI app, it should be bin/kconfig_compiler,
not bin/kconfig_compiler.app.
good point, well then I guess there's a bug in the build system, or
cmake 2.4 (branch) CVS, 'cause it's making an .app bundle. Maybe I
just
On 5/30/06, Paulo Moura Guedes [EMAIL PROTECTED] wrote:
There is still some problem, not sure if it's the library not being found
though. Hard to tell with no Mac to try.
I just remembered, the continuous build removes the cache? I needed to remove
it on my PC...
my continuous build (the g4
On 5/29/06, David Faure [EMAIL PROTECTED] wrote:
But kconfig_compiler is a NOGUI app, it should be bin/kconfig_compiler,
not bin/kconfig_compiler.app.
actually, it's a NO_GUI app, and it's supposed to be NOGUI. :P
I fixed it in trunk and kdelibs4_snapshot
Is there any way to get cmake to build libraries in osx versioning style?
linux and presumably others use the form:
libfoo.so.1.0.0
whereas osx uses:
libfoo.1.0.0.dylib
it doesn't really hurt anything, but the other form is preferable.
___
The Mac OS X 10.3 dashboard is failing because apparently the
libdbus-qt4-1.dylib does not encode the full path in the binary:
$ otool -L libdbus-qt4-1.dylib
libdbus-qt4-1.dylib:
libdbus-qt4-1.dylib.1 (compatibility version 0.0.0, current
version 0.0.0)
On 6/9/06, Thiago Macieira [EMAIL PROTECTED] wrote:
I have no idea what it is. I just use LD_LIBRARY_PATH (DYLD_LIBRARY_PATH
in your case) to point to the right dirs, since I didn't install the
library in a well-known path.
According to the cmake devs, rpath can bring serious problems, so
On 6/30/06, Paulo Jorge Guedes [EMAIL PROTECTED] wrote:
I'm changing to Qt-4.2 TP on the mingw dashboard.
Don't know if it works but Qt-4.1.x is broken anyway.
OK, I'll update the macs too. Quite a few of the qt-copy patches are
already there, should I not apply any of them? Or is someone
On 6/30/06, David Faure [EMAIL PROTECTED] wrote:
Whoever updates qt-copy will also update the patches there.
But right now, for qt-copy, we have to wait for the GPL version of Qt-4.2-TP,
or for a TT employee to update qt-copy... (please!)
OK, for now I'll just apply the qt-copy define patch
On 7/2/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
A continuous build has been broken for KDE and you have been identified
as one of the authors who have checked in changes that are part of this build.
FYI, the mac dashboards are updated to qt/mac 4.2 tp1 (+ qt-copy
patches dir) so these
On 7/3/06, Alexander Neundorf [EMAIL PROTECTED] wrote:
QtDBus is not yet supported under Windows. This unfortunately means that
kdelibs currently cannot be compiled under Windows :-/
Speaking of, it looks like the dbus tools don't get installed on a
make install of Qt. It also looks like
On 7/3/06, Alexander Neundorf [EMAIL PROTECTED] wrote:
Current qt-copy ?
If they are not built or installed, enter src/tools/qdbus/, run qmake, make
and make install and then it should get installed.
It looks like I had failed to put my dbus pkgconfig bits in the
PKG_CONFIG_PATH before
On 7/6/06, Alexander Neundorf [EMAIL PROTECTED] wrote:
Can you please also post the output of gcc --version ?
Sorry, I put more detail in the bug, when I realized it was bigger
than just is this regex wrong?
http://www.cmake.org/Bug/bug.php?op=showbugid=3483
On 7/6/06, Alexander Neundorf [EMAIL PROTECTED] wrote:
SVN commit 559236 by neundorf:
-fix gcc version detection on Mac
CCMAIL: [EMAIL PROTECTED]
Can you please check that this works now for you ?
according to the latest dashboard it looks like it does; it's got
different build errors now.
On 8/24/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Errors for this build are here:
http://public.kitware.com/KDE/Testing/Sites/imac-x86.befunk.com/i386-Apple-MacOSX-10.4-gcc4.0/20060824-1338-Continuous/BuildError.html
so did I jump the gun in switching to the new Qt4 snapshot? I'm not
So I replaced the qt4 build on my dashboard box, and now cmake is no
longer detecting QtDbus properly.
I get the _RELEASE and _DEBUG bits set:
---(snip!)---
//The QtDBus library.
QT_QTDBUS_LIBRARY_DEBUG:STRING=-framework QtDBus
//The QtDBus library.
QT_QTDBUS_LIBRARY_RELEASE:STRING=-framework
On 8/24/06, Benjamin Reed [EMAIL PROTECTED] wrote:
...but I'm missing QT_QTDBUS_LIBRARY:FILEPATH=-F/opt/qt4/lib
-framework QtDBus which I believe should be there. Other Qt bits are
found properly (and AFAIK are found in the same way):
to answer my own question, the latest qt-mac 4.2
On 8/26/06, Erik L. Bunce [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] list. If you are interested in the Qt
patch it can be found at: http://kde.bunce.us/qt-mac-20060824.patch
I ran into the same qtdbus issue as you, but I'm confused, why are you
making command-line tools like dbusxml2cpp into
Somehow, in my build, -I/opt/kde4-deps/include has gone missing.
---(snip!)---
/usr/bin/c++ -Dpigment_EXPORTS -arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -fno-common -O2 -g
-fPIC
On 8/28/06, Alexander Neundorf [EMAIL PROTECTED] wrote:
Doesn't this add LCMS_INCLUDE_DIR before it gets defined by
find_package(LCMS) ? If it's done in this order, LCMS_INCLUDE_DIR will most
probably be empty in the INCLUDE_DIRECTORIES() call.
Looks like that did it. At first I thought it
On 9/11/06, Benjamin Reed [EMAIL PROTECTED] wrote:
CMake Error: Error in cmake code at
/Users/ranger/cvs/packages/source.build/kdelibs/cmake/modules/FindKDE4Internal.cmake:188:
MESSAGE Qt4 dbusxml2cpp was not found. Make sure it has been built and
installed by Qt
OK, I tried even copying
So I'm using the test patches discussed earlier, and it doesn't seem
to have helped. Anyone have any solutions for this? Right now the
dashboard's useless if it prints an error for every build, I'm sure no
one's watching it.
Attached are my .cmake file for the continuous build, and the patch
If I do a fresh build of kdepim, it finds everything properly:
---(snip!)---
--
-- The following list of OPTIONAL packages were located on your
system. --
-- You will have all the following features available
in kdeedu's ConfigureChecks.cmake, I see this:
check_include_files(termios.h TERMIOS_FOUND)
macro_bool_to_01(TERMIOS_FOUND HAVE_TERMIOS_H)
...from what I can tell, it's supposed to define HAVE_TERMIOS_H to 1
or 0 depending on whether termios.h is found.
My CMakeCache.txt in kdeedu seems to
On 12/19/06, Alexander Neundorf [EMAIL PROTECTED] wrote:
Can you please update your kdepim/CMakeLists.txt and run both cases again ?
I'm interested in the output again.
...now I get this, which is even weirder, it doesn't say anything
further down about the required gpgme stuff, but I do get
my kdenetwork build on mac is failing right now because of qca2.
The problem is, pkg-config says that qca2's include is at
/opt/kde4-deps/include/QtCrypto (which is correct), but FindQCA2 is
somehow stripping it out:
-- pkg-config returned /opt/kde4-deps/include/QtCrypto for QCA 2 includes
--
On 1/5/07, Brad Hards [EMAIL PROTECTED] wrote:
Does this work for you:
...
+PKGCONFIG(qca QCA2_INCLUDE_DIR _Qca2LinkDir _Qca2LinkFlags _Qca2Cflags)
MESSAGE(STATUS pkg-config returned ${_Qca2IncDir} for QCA 2 includes)
set(QCA2_DEFINITIONS ${_Qca2Cflags})
+ ELSE (NOT WIN32)
On 1/21/07, Thiago Macieira [EMAIL PROTECTED] wrote:
I have just noticed I have reenabled -fvisibility-inlines-hidden in trunk.
In branches, it was dependent on a test for a gcc bug that doesn't happen
on i386.
Should I re-add the test? Or is the bug fixed in gcc 4.1.0? I couldn't
really
On 1/21/07, Thiago Macieira [EMAIL PROTECTED] wrote:
...
That's the test that enabled -fvisibility-inlines-hidden and that was not
ported to CMake.
My question is: is the test necessary or does gcc 4.1.0 already
incorporate the fix?
Considering it works with Apple's 4.0.1, I would like to
On 3/8/07, Alexander Neundorf [EMAIL PROTECTED] wrote:
A short note on kde-core-devel whenever updating qt-copy is required would
indeed be nice :-)
Especially since those of us on alternative platforms can't use
qt-copy since it's really qt-x11-copy. ;)
On 3/12/07, Alexander Neundorf [EMAIL PROTECTED] wrote:
Does OS X actually have RPATH ? I thought it only supports the install_name
thingy. How should it behave ?
I was referring to the install_name thingy, it just happens to have a
simliar effect to rpath.
Should the rpath stuff be broken
I'm trying to do a make install on the latest strigi and I get this:
---(snip!)---
...
-- Installing /opt/kde4-deps/include/strigi/fieldtypes.h
--
Installing /opt/kde4-deps/lib/libstreamanalyzer.0.3.11.dylib
FindFreetype in kdelibs/cmake/modules seems to have an issue.
Currently, it does this:
---(snip!)---
EXEC_PROGRAM(${FREETYPECONFIG_EXECUTABLE} ARGS --cflags
RETURN_VALUE _return_VALUE OUTPUT_VARIABLE FREETYPE_INCLUDE_DIR)
if(FREETYPE_LIBRARIES AND FREETYPE_INCLUDE_DIR)
On 4/7/07, Bill Hoffman [EMAIL PROTECTED] wrote:
So March 9th was the last day a dashboard was submitted to the kde
dashboard at Kitware.
http://public.kitware.com/dashboard.php?name=kde
Do you still want Kitware to run this? I know for a while it was
keeping the windows
build working
On 4/8/07, Brad Hards [EMAIL PROTECTED] wrote:
On Saturday 07 April 2007 00:38, Benjamin Reed wrote:
When I try to build something that does:
INCLUDE_DIRECTORIES( ${FREETYPE_INCLUDE_DIR} )
I end up with this on the compile line:
-I/opt/kde4-deps/include/freetype2\ -I/opt/kde4
On 6/5/07, Alexander Neundorf [EMAIL PROTECTED] wrote:
Can you create a minimal testcase where the linker crashes ? This would be a
big help.
I suspect by definition it has to be a maximal test case, but I'll see
what I can do.
___
Kde-buildsystem
On Jan 2, 2008 11:11 AM, Alexander Neundorf [EMAIL PROTECTED] wrote:
it would be nice if somebody besides me could give CMake 2.4.8 RC9 a try.
This will be the last CMake 2.4.x release and as such it would really suck if
it would have a problem building KDE 4.
I tested it on my machine and I
at the cmake level? Right now kdepim is unlinkable on Mac
OS X, and it will only get worse if more dependencies are added.
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http://www.racoonfink.com/
___
Kde-buildsystem mailing list
Kde
On Jan 7, 2008 11:27 AM, Bill Hoffman [EMAIL PROTECTED] wrote:
Can you create a bug report for this in the CMake bug tracker?
Heh, went to do so, and it turns out I already opened one... =)
http://www.cmake.org/Bug/view.php?id=4810
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X
/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
Is this some kind of relink issue? It only seems to happen for
programs, not for libraries...
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http://www.racoonfink.com
On Jan 13, 2008 9:38 AM, Benjamin Reed [EMAIL PROTECTED] wrote:
Since upgrading (from 2.4.6 I believe) to the RCs, all .app-bundles
are referencing the build-dir versions of libraries, rather than their
final rpath:
false alarm, it looks like this is what broke it:
http://websvn.kde.org
/compile.build/kdelibs/CMakeFile
s/CMakeTmp/CheckSymbolExists.c
/Users/ranger/cvs/kde-mac/compile.build/kdelibs/CMakeFiles/CMakeTmp/CheckSymbolExists.c:2:18:
error: pcre.h: No such file or directory
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http://www.racoonfink.com
giving me
the name of the list specified in CMakeLists.txt, not a list.
Any ideas what's going wrong?
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http://www.racoonfink.com/
___
Kde-buildsystem mailing list
Kde-buildsystem
are all static, in libkommanderplugin, so I presume
they shouldn't actually be directly available to kommanderwidget?
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http://www.racoonfink.com/
___
Kde-buildsystem mailing list
Kde
the
data to a file or pipe in several different formats
http://www.xiph.org/paranoia/
Required for building the AudioCD ioslave.
-
Any idea how to fix this?
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X
On Feb 19, 2008 3:43 AM, Laurent Montel [EMAIL PROTECTED] wrote:
I think that I fixed pb in kdelibs/cmake/modules/FindXine.cmake
could you update it please and test it please ?
thanks regards
Looks like that did it, thanks!
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X
/libpng.dylib:
Mach header
magic cputype cpusubtype capsfiletype ncmds sizeofcmds flags
MH_MAGICI386ALL 0x00 DYLIB11 1228
NOUNDEFS DYLDLINK TWOLEVEL SUBSECTIONS_VIA_SYMBOLS
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http
kdelibs/etc. macros have changed since I last tried
to build?
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http://www.racoonfink.com/
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde
DESTINATION lib fixes it; but I would say that if
BUNDLE DESTINATION is not set, cmake should fall back to whatever
LIBRARY DESTINATION is set to.
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http://www.racoonfink.com/
___
Kde
On Tue, Apr 15, 2008 at 1:26 PM, Alexander Neundorf [EMAIL PROTECTED] wrote:
Does it now also work with Brads fix and without local modifications ?
a fix to cmake cvs? I can try building it and testing...
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http
. Run cmake --help-policy CMP0006 for policy details.
Use the cmake_policy command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.
Thanks for the help!
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http
for me...)
bash-3.2# cd phonon; make install DESTDIR=/tmp/foo
...
bash-3.2# otool -L /tmp/foo/opt/kde4/lib/libphonon.dylib
/tmp/foo/opt/kde4/lib/libphonon.dylib:
/opt/kde4/lib/libphonon.4.dylib (compatibility version 0.0.0, current
version 0.0.0)
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE
undefined symbols (without some work)... do you know if anyone's
tested this stuff with mac yet? Is it easy to turn off? =)
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
Blog: http://www.raccoonfink.com/
Music: http://music.raccoonfink.com
to confirm.
I'm getting a little lost in this thread, is there a summary on how to
give all of this a shot and test on OSX to make sure it still works?
Is there a full patchset somewhere?
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
Blog: http://www.raccoonfink.com/
Music: http
maximum input.
As the guy who currently hasn't had time to do a new build for KDE/Mac
for *ahem* months, I'd love to make it easier for people to more
repeatably create packages. I think this would be great!
- --
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
Blog: http
the initial cmake command.
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
Blog: http://www.raccoonfink.com/
Music: http://music.raccoonfink.com/
getlibrarynamesinternal.tar.bz2
Description: BZip2 compressed data
___
Kde
a smaller test case yet. ;)
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
Blog: http://www.raccoonfink.com/
Music: http://music.raccoonfink.com/
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org
to /usr/lib so people wouldn't hit
these types of bugs.
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
Blog: http://www.raccoonfink.com/
Music: http://music.raccoonfink.com/
___
Kde-buildsystem mailing list
Kde-buildsystem
: QtUiTools/QUiLoader: No such file or directory
What do you think is the sanest way to work around this? I can
symlink the files into my KDE root (/opt/kde4), or maybe have one of
the KDE internal macros link them in the build dir, maybe?
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X
because I have got KDE building with Qt/X11 on Mac OS
X as well as with Qt/Mac.
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
Blog: http://www.raccoonfink.com/
Music: http://music.raccoonfink.com/
___
Kde-buildsystem mailing list
, which then causes conflicts at link-time.
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
Blog: http://www.raccoonfink.com/
Music: http://music.raccoonfink.com/
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https
/Versions/4/Headers/QGraphicsObject for me. Yes I'm
using frameworks on OSX 10.6 with Qt 4.6.2/Cocoa.
As long as your -F's are right, then
lib/QtGui.framework/Versions/4/Headers/QGraphicsObject should work
with:
#include QtGui/QGraphicsObject
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac
78 matches
Mail list logo
