Hi,
attached patch only sets the QT_MIN_VERSION if its not been set already.
The reason for this is that it may be useful for a project to require a
specific Qt bugfix version (for example if a bug makes an app unusable).
In particular I'd like KDevelop4 to require Qt4.5.2 as we need Qt's
raster
On 13.09.09 19:16:07, Alexander Neundorf wrote:
On Sunday 13 September 2009, Ingo Klöcker wrote:
On Sunday 13 September 2009, Andreas Pakulat wrote:
Hi,
attached patch only sets the QT_MIN_VERSION if its not been set
already. The reason for this is that it may be useful
On 03.09.09 20:08:17, Alexander Neundorf wrote:
On Thursday 03 September 2009, Dario Freddi wrote:
Also (sorry for flooding) just read about the cmake files needed to be sent
to kde-buildsystem for review. So please, your target is
cmake/modules/MacroKAuth.cmake.
By the way, what about
On 03.09.09 22:02:52, Alexander Neundorf wrote:
On Thursday 03 September 2009, Andreas Pakulat wrote:
On 03.09.09 20:08:17, Alexander Neundorf wrote:
On Thursday 03 September 2009, Dario Freddi wrote:
Also (sorry for flooding) just read about the cmake files needed to be
sent to kde
On 28.08.09 17:18:47, Michael Jansen wrote:
I'm compiling quite a bit of kde with my own scripts. I prefer to compile
smaller packages for convenience. While doing that i noticed we don't have a
policy for directories like:
http://websvn.kde.org/trunk/playground/devtools
On 28.08.09 20:53:06, Michael Jansen wrote:
On Friday 28 August 2009 20:18:19 you wrote:
On 28.08.09 17:18:47, Michael Jansen wrote:
I'm compiling quite a bit of kde with my own scripts. I prefer to compile
smaller packages for convenience. While doing that i noticed we don't
have a
On 27.08.09 00:08:26, Thiago Macieira wrote:
Em Quarta-feira 26. Agosto 2009, às 23.25.52, Christoph Feck escreveu:
The problem is that QtTest headers (from 4.6-stable branch) conditionally
define GUI related classes based on the QT_GUI_LIB define to avoid linking
with QtGui on pure
On 10.08.09 12:31:23, Allan Sandfeld Jensen wrote:
Hi
I've been trying to resolve a problem I got when configuring varies KDE 4
modules. CMake complains that it can not sane search paths for some libraries
in particular qimageblitz and polkitqt. The reason it can set the search path
is
On 07.08.09 00:27:13, Thiago Macieira wrote:
Thiago Macieira wrote:
Fathi Boudra wrote:
Hi,
At the moment, Phonon backends are installed inside
${LIB_INSTALL_DIR}/kde4/plugins/ which seems wrong.
Whatever you decide is right, don't touch Qt's installation.
Let me explain:
Unless
On 18.07.09 03:01:31, Aleix Pol wrote:
hi,
I've hit a problem when compiling a KDevelop test using gold. If we use the
usual ld it works fine but with gold it requires all the libraries to be
specified. As for what Andreas told me, it looks like linking against the
language would be enough to
On 08.07.09 15:29:17, Mike Arthur wrote:
This is probably a stupid question but why do we duplicate modules
like FindQt4 in the KDE SVN? These are included in the latest required
versions of CMake. On OSX this actually causes a bug (due to bugs in
FindQt4) where various Qt libraries cannot be
On 08.07.09 16:08:10, Mike Arthur wrote:
2009/7/8 Andreas Pakulat ap...@gmx.de:
That usually happens when there are bugs in the FindXXX modules in cmake,
in particular in the cmake version we require (current 2.6.2 I think). Or
if the cmake version we require doesn't ship a suitable FindXXX
On 26.06.09 14:25:07, David Faure wrote:
On Thursday 25 June 2009, David Faure wrote:
+target_link_libraries(nepomuk LINK_INTERFACE_LIBRARIES
${KDE4_KDEUI_LIBS} ${SOPRANO_LIBRARIES})
Is this supposed to be exported somehow? It works in kdelibs but linking
still fails
similarly in
On 26.06.09 14:38:23, Andreas Pakulat wrote:
On 26.06.09 14:25:07, David Faure wrote:
On Thursday 25 June 2009, David Faure wrote:
+target_link_libraries(nepomuk LINK_INTERFACE_LIBRARIES
${KDE4_KDEUI_LIBS} ${SOPRANO_LIBRARIES})
Is this supposed to be exported somehow? It works
On 26.06.09 16:36:50, David Faure wrote:
On Friday 26 June 2009, Brad King wrote:
Andreas Pakulat wrote:
So maybe link-interface-libs really only works within the same cmake
project (I've always wondered where cmake stores this information so that
it works across projects
Resending as Alex lost his copy and I'd like to get his answer easily
onto this list, hope the other readers don't mind.
On 07.06.09 21:50:06, Andreas Hartmetz wrote:
On Sunday 07 June 2009 01:39:56 Andreas Pakulat wrote:
On 06.06.09 21:05:34, Andreas Hartmetz wrote:
SVN commit 978363
On 15.06.09 19:42:45, Alexander Neundorf wrote:
On Thursday 04 June 2009, Andreas Pakulat wrote:
On 04.06.09 15:11:04, Chris Bruner wrote:
Andreas Pakulat wrote:
On 04.06.09 13:34:48, Chris Bruner wrote:
I'm new to this list so sorry if I'm tramping over old ground,
(didn't see
On 15.06.09 14:26:22, Matthew Woehlke wrote:
Alexander Neundorf wrote:
Still, why doesn't the cmake code from kdesupport/akonadi/CMakeLists.txt
work
for you ?
I think it gets confused when soprano is no longer in the location
specified in the cache. I'm working on reproducing now,
On 11.06.09 10:57:38, Sean Tilley wrote:
I've recently been attempting to build the latest /trunk of KDE on gNewsense
for educational purposes, however after building Cmake 2.6-4, Qt 4.5.1, and
kdesupport, I am completely unable to complete building kdelibs.
The output can be found at:
On 07.06.09 21:50:06, Andreas Hartmetz wrote:
On Sunday 07 June 2009 01:39:56 Andreas Pakulat wrote:
On 06.06.09 21:05:34, Andreas Hartmetz wrote:
SVN commit 978363 by ahartmetz:
link with gold
M +6 -4 git/tests/CMakeLists.txt
M +2 -0 mercurial/tests
On 06.06.09 11:15:11, Oswald Buddenhagen wrote:
On Sat, Jun 06, 2009 at 10:59:40AM +0200, Thiago Macieira wrote:
Oswald Buddenhagen wrote:
that's a sign that the plugin system needs to be fixed, not that
the build system should be screwed up to compensate for it.
specifically, installing
On 04.06.09 23:49:14, David Jarvie wrote:
I'm creating a separate package for KAlarm, and want to default its
installation path to the KDE installation directory. In CMakeLists.txt I've
got:
find_package(KDE4 4.1.0 REQUIRED)
if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
On 05.06.09 14:44:36, David Jarvie wrote:
On Friday 5 June 2009 11:42, Andreas Pakulat wrote:
On 05.06.09 10:20:25, David Faure wrote:
You need to set $KDEDIRS somewhere that kde startup will read, and rerun
kbuildsycoca4, when you use another prefix than your KDE install prefix.
So
On 05.06.09 18:12:53, David Faure wrote:
On Friday 05 June 2009, Andreas Pakulat wrote:
How come they know how to checkout from svn and use
cmake in the first place if they haven't read some kind of tutorial?
Who said anything about svn? People download and compile tarballs.
Same
On 05.06.09 19:42:12, Michael Jansen wrote:
will screw their /usr directory.
How? Typically make install as user is not able to write into
root-owned /usr. So it has to be intentionnal, anyway, in that setup.
/usr/local is root owned too. At least here. So many tutorials say
Ah,
On 28.05.09 22:32:58, Alexander Neundorf wrote:
On Monday 25 May 2009, Andreas Pakulat wrote:
Hi,
I just came across a not-so-nice difference between the FindQt4.cmake in
kdelibs vs. the one in cmake 2.6.4. The kdelibs version doesn't set
QT_VERSION_MAJOR/MINOR/PATCH while the cmake one
On 28.05.09 23:49:45, Alexander Neundorf wrote:
On Thursday 28 May 2009, Andreas Pakulat wrote:
On 28.05.09 22:32:58, Alexander Neundorf wrote:
On Monday 25 May 2009, Andreas Pakulat wrote:
Hi,
I just came across a not-so-nice difference between the FindQt4.cmake
in kdelibs
Hi,
I just came across a not-so-nice difference between the FindQt4.cmake in
kdelibs vs. the one in cmake 2.6.4. The kdelibs version doesn't set
QT_VERSION_MAJOR/MINOR/PATCH while the cmake one does set them.
Additionally the kdelibs-version version doesn't advertize the QTVERSION
variable that
On 13.05.09 18:37:53, Alexander Neundorf wrote:
On Tuesday 12 May 2009, Pino Toscano wrote:
Alle martedì 12 maggio 2009, Christophe Giboudeaux ha scritto:
5/ Considering 1,2 and 3, I still didn't read any valid reason for using
the same prefix as kdelibs, kdebase, kdegames etc... and add
On 11.05.09 23:23:25, Pino Toscano wrote:
Alle lunedì 11 maggio 2009, Christophe Giboudeaux ha scritto:
SVN commit 966746 by cgiboudeaux:
As mentioned by Alex when KDEPIMLIBS_INCLUDE_DIRS was created, installing
the kdepimlibs CamelCase headers in the same dir as the kdelibs ones is not
On 12.05.09 10:54:32, Pino Toscano wrote:
Alle martedì 12 maggio 2009, Andreas Pakulat ha scritto:
On 11.05.09 23:23:25, Pino Toscano wrote:
Alle lunedì 11 maggio 2009, Christophe Giboudeaux ha scritto:
SVN commit 966746 by cgiboudeaux:
As mentioned by Alex when
On 12.05.09 18:20:53, Pino Toscano wrote:
Alle martedì 12 maggio 2009, Andreas Pakulat ha scritto:
to $prefix/include/KDEPimLibs.
Isn't $prefix/include/KDE namespaced already?
Yes, across all of KDE main modules, which might or might not be enough. If
KDevPlatform would install
On 11.05.09 22:59:15, Alexander Neundorf wrote:
On Monday 11 May 2009, Christophe Giboudeaux wrote:
SVN commit 966746 by cgiboudeaux:
As mentioned by Alex when KDEPIMLIBS_INCLUDE_DIRS was created, installing
the kdepimlibs CamelCase headers in the same dir as the kdelibs ones is not
a
On 12.05.09 21:54:02, Pino Toscano wrote:
Alle martedì 12 maggio 2009, Christophe Giboudeaux ha scritto:
5/ Considering 1,2 and 3, I still didn't read any valid reason for using
the same prefix as kdelibs, kdebase, kdegames etc... and add more files
inside /KDE.
Coherency with other
SVN commit 966265 by apaku:
Reduce this file to a minimal version, CMake 2.6.2 ships with a quite good and
improved (compared to this version) FindBoost.cmake.
For backward compatibility we're adding 1.37 to Boost_ADDITIONAL_VERSIONS, that
should stay the only version in this file, so once we
On 06.05.09 23:10:26, Pino Toscano wrote:
Alle mercoledì 06 maggio 2009, Alexander Neundorf ha scritto:
Or how about that ?
Instead of completely removing FindBoost.cmake, we replace it with an
almost empty one:
set(Boost_ADDITIONAL_VERSIONS 1.39.0 1.39 1.38.0 1.38
On 06.05.09 00:15:24, Pino Toscano wrote:
Alle martedì 05 maggio 2009, Andreas Pakulat ha scritto:
On 14.04.09 19:15:17, Alexander Neundorf wrote:
On Saturday 11 April 2009, Andreas Pakulat wrote:
as cmake 2.6.2 and 2.6.3 ship with very good FindBoost.cmake files and
the module has
On 29.04.09 11:33:05, Andrew Coles wrote:
SVN commit 960968 by coles:
Likewise, need to add the library path too.
M +1 -0 CMakeLists.txt
--- trunk/KDE/kdelibs/kdecore/CMakeLists.txt #960967:960968
@@ -44,6 +44,7 @@
# compile lzma support if available
if(LIBLZMA_FOUND)
On 27.04.09 21:29:44, Alexander Neundorf wrote:
Hi Helio,
two weeks have almost passed, please have a look at the FindLibLZMA.cmake you
committed and fix the issues listed below.
We have a hard feature freeze coming up and apparently the author currently
doesn't have time to work on this
On 22.04.09 11:15:32, Allen Winter wrote:
Howdy,
It seems to me that FindSoprano.cmake needs some love.
In particular, it does stuff like:
find_path(SOPRANO_INCLUDE_DIR
NAMES
soprano/soprano.h
PATHS
${KDE4_INCLUDE_DIR}
${INCLUDE_INSTALL_DIR}
)
which I
On 14.04.09 19:15:17, Alexander Neundorf wrote:
On Saturday 11 April 2009, Andreas Pakulat wrote:
Hi,
as cmake 2.6.2 and 2.6.3 ship with very good FindBoost.cmake files and
the module has a dedicated maintainer who quickly responds to
bugreports, how about removing the one in kdelibs
Hi,
as cmake 2.6.2 and 2.6.3 ship with very good FindBoost.cmake files and
the module has a dedicated maintainer who quickly responds to
bugreports, how about removing the one in kdelibs? If removing is not an
option, we should at least update it to the version thats being shipped
with CMake
On 10.04.09 01:53:07, Tomáš Chvátal wrote:
Dne pátek 10 Duben 2009 01:35:29 Andreas Pakulat wrote:
*snip*
Regarding kdepim, why not just install kabc2mutt as symlink to
kabcclient?
Because at least one platform of KDE4 doesn't support symlinks.
Andreas
Wont it be smart
On 10.04.09 00:30:57, Maciej Mrozowski wrote:
Hi
I've just noticed little problem with one executable from kdepim.
kabcclient is intentionally installed in two copies with different names
(logic is determined by argv[0]), using install ( RENAME )
Looks like cmake install ( RENAME )
On 06.02.09 09:27:25, Matthias Kretz wrote:
Hi,
fixed with rev. 922011 of kdesupport/automoc
Doesn't work here, I still get such errors from moc-files that were
generated with qt 4.4. automoc is up-to-date.
Andreas
--
You will be a winner today. Pick a fight with a four-year-old.
On 11.02.09 19:33:52, Andreas Pakulat wrote:
On 06.02.09 09:27:25, Matthias Kretz wrote:
Hi,
fixed with rev. 922011 of kdesupport/automoc
Doesn't work here, I still get such errors from moc-files that were
generated with qt 4.4. automoc is up-to-date.
Oh, sorry. Misunderstood what
On 13.01.09 14:05:34, Andreas Pakulat wrote:
On 13.01.09 00:29:34, Alexander Neundorf wrote:
On Monday 12 January 2009, Andreas Pakulat wrote:
On 11.01.09 17:15:01, Alexander Neundorf wrote:
Hi,
if you are using CMake (well, all of you are :-) ), I finally took the
time
On 29.01.09 12:37:32, Hasso Tepper wrote:
Andreas Pakulat wrote:
Fix finding libical headers and also use TO_CMAKE_PATH instead of
string-replacing.
Now libical isn't found at all in my system because /usr/local was
removed from search paths.
In fact I always wondered why I had to add
On 28.01.09 18:20:50, Allen Winter wrote:
On Wednesday 28 January 2009 5:43:04 pm Andreas Pakulat wrote:
On 28.01.09 22:11:10, Alexander Neundorf wrote:
On Wednesday 28 January 2009, Andreas Pakulat wrote:
Hi,
currently FindLibical.cmake doesn't produce a proper
Hi,
currently FindLibical.cmake doesn't produce a proper LIBICAL_INCLUDE_DIRS
variable. That variable always contains the PATH_SUFFIX which means its
prefix/include/libical. However the libical headers themselves expect
only prefix/include to be set as include dir.
This works fine as long as one
On 28.01.09 22:11:10, Alexander Neundorf wrote:
On Wednesday 28 January 2009, Andreas Pakulat wrote:
Hi,
currently FindLibical.cmake doesn't produce a proper LIBICAL_INCLUDE_DIRS
variable. That variable always contains the PATH_SUFFIX which means its
prefix/include/libical. However
On 20.01.09 21:29:48, Alexander Neundorf wrote:
On Monday 19 January 2009, Andreas Pakulat wrote:
On 18.01.09 23:33:21, Andreas Pakulat wrote:
...
The problem with that is when a new version is out.
Not really, if a project uses boost, one of its dev should _check_ that
it still
On 18.01.09 02:22:30, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 2:09 AM, Allen Winter win...@kde.org wrote:
On Saturday 17 January 2009 7:51:44 pm Pau Garcia i Quiles wrote:
Hello,
FindBoost.cmake in that version of kdesupport and in CMake 2.6.2 does
not support Boost 1.37.0.
On 18.01.09 12:50:32, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 11:28 AM, Andreas Pakulat ap...@gmx.de wrote:
On 18.01.09 02:22:30, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 2:09 AM, Allen Winter win...@kde.org wrote:
On Saturday 17 January 2009 7:51:44 pm Pau Garcia i
On 18.01.09 23:33:21, Andreas Pakulat wrote:
On 18.01.09 12:50:32, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 11:28 AM, Andreas Pakulat ap...@gmx.de wrote:
On 18.01.09 02:22:30, Pau Garcia i Quiles wrote:
On Sun, Jan 18, 2009 at 2:09 AM, Allen Winter win...@kde.org wrote
On 13.01.09 00:29:34, Alexander Neundorf wrote:
On Monday 12 January 2009, Andreas Pakulat wrote:
On 11.01.09 17:15:01, Alexander Neundorf wrote:
Hi,
if you are using CMake (well, all of you are :-) ), I finally took the
time to write a page at techbase which documents (hopefully
On 11.01.09 17:15:01, Alexander Neundorf wrote:
Hi,
if you are using CMake (well, all of you are :-) ), I finally took the time
to
write a page at techbase which documents (hopefully) all changes to our
buildsystem in KDE 4.2 compared to 4.0/4.1:
Hi,
since the recent changes (the build is about a week old) I seem to be
getting lots of linker-search path errors for kdebase:
Make Warning at /usr/local/share/apps/cmake/modules/KDE4Macros.cmake:823
(add_executable):
Cannot generate a safe linker search path for target plasma_qgv because
On 08.01.09 21:32:39, David Faure wrote:
On Thursday 08 January 2009, Andreas Pakulat wrote:
dir 0 is [/home/andreas/src/build/kdebase/lib]
dir 1 must precede it due to link library [libplasma.so.3.0.0]
Delete libplasma.so* from that directory, it doesn't belong there anymore
On 09.12.08 11:47:47, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Maciej Mrozowski rašė:
I noticed those files are installed in
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceConfig.cmake
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceLibraryTargets-
On 09.12.08 12:23:18, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Andreas Pakulat rašė:
Because /usr/share is for non-platform specific data and those files
contain platform specific information (in particular they contain paths to
things like the library files
Hi,
I think the reduced linking stuff is already active for win32, at least I
get a lot of new linking errors trying to compile kdevelop. For libraries
which until now were included in some of the kdevplatform libraries that
the targets in question already link against.
Thats not a big deal,
On 16.11.08 01:15:24, Bo Ørsted Andresen wrote:
On Saturday 15 November 2008 07:52:25 Andreas Pakulat wrote:
@zlin ok, the problem is there is a name space conflict
@zlin pkg_check_modules(QCA2 qca2) marks QCA2_LIBRARIES as INTERNAL
and assigns a list of libraries to it
@zlin
On 16.11.08 20:21:15, Alexander Neundorf wrote:
we have a bunch of cmake-built projects in kdesupport/. We have FindFoo.cmake
modules for them in kdelibs/.
These FindFoo.cmake modules don't take advantage of the fact that these
packages have also been built with cmake, they just search for
On 16.11.08 22:35:28, Alexander Neundorf wrote:
On Sunday 16 November 2008, Manuel Sput Nickschas wrote:
On Sunday 16 November 2008 20:56:41 Alexander Neundorf wrote:
Can we please fix FindQCA2.cmake and not the applications using it?
We had some policy to preserve how the Find*.cmake
On 14.11.08 16:18:31, Johannes Manhave wrote:
I've been having problems compiling anything that uses QCA2 in kde
trunk, using genkdesvn on gentoo.
I spoke about it with one of the devs from there and he came up with this:
@zlin ok, the problem is there is a name space conflict
@zlin
[moving to just kde-buildsystem]
On 12.11.08 22:44:22, Alexander Neundorf wrote:
On Tuesday 11 November 2008, Andreas Pakulat wrote:
On 11.11.08 01:00:50, Alexander Neundorf wrote:
...
# No changes so far, but the next line is new.
# It specifies to which libraries other targets
On 11.11.08 01:00:50, Alexander Neundorf wrote:
Hi,
as of now cmake 2.6.2 is required to build KDE4 trunk.
This brings some bugfixes, some nice features and one relatively big change,
which concerns shared library handling.
Warning: if you get linker errors or errors related to
On 06.11.08 09:58:18, David Faure wrote:
On Thursday 06 November 2008, Andreas Pakulat wrote:
So just remove the setting of CMAKE_CONFIGURATION_TYPES completely.
I thought it was useful for showing that debugfull is available, in ccmake?
Only if it is not set I think. At least here I only
On 06.11.08 18:20:44, Alexander Neundorf wrote:
On Thursday 06 November 2008, Andreas Pakulat wrote:
On 06.11.08 09:58:18, David Faure wrote:
On Thursday 06 November 2008, Andreas Pakulat wrote:
So just remove the setting of CMAKE_CONFIGURATION_TYPES completely.
I thought
On 06.11.08 00:34:08, Alexander Neundorf wrote:
On Saturday 19 July 2008, Andreas Pakulat wrote:
On 18.07.08 23:06:50, Alexander Neundorf wrote:
Thanks for the explanation :-)
Can you put that on techbase, somewhere related to cmake/building ?
I'm putting it on techbase in a minute
On 06.11.08 00:25:39, Alexander Neundorf wrote:
On Wednesday 05 November 2008, Brad King wrote:
Manuel Sput Nickschas wrote:
...
While in theory and according to cmake docs this should just add the
additional build configuration to a list of existing ones, in reality
this adds
Matthew Woehlke wrote:
This looks to be caused by the simplification of FindKDevPlatform 9 days
ago (I don't think I've built since then, anyway).
It seems that, unlike the Find's for automoc, strigi, etc,
FindKDevPlatform does not check CMAKE_INSTALL_PREFIX. Since most people
are
On 02.10.08 17:40:52, Augusto Leite wrote:
Hi,
I am trying to compile KDE from sources, but cmake installs it on
DebugFull mode. I am to install it on Release mode.
I changed the script (from kde.org) and used:
cmake $srcFolder -DCMAKE_INSTALL_PREFIX=$KDEDIR -DCMAKE_BUILD_TYPE=Release
On 01.10.08 18:18:07, Brad King wrote:
Andreas Pakulat wrote:
On 01.10.08 23:59:51, Alexander Neundorf wrote:
Yes, I think your third option is what I would prefer: the package
installs a
FooConfig.cmake file with all the necessary information and macros, and
then
we need only
Hi,
the new nepomuk stuff breaks the kdebase build for me. In particular it
expects the dbus xml files to be installed when building
workspace/lib/nepomukqueryclient. The problem is that it thinks that its
building the workspace separately, which is not happening.
This ahppens because
On 17.09.08 22:47:00, Andreas Pakulat wrote:
Hi,
the new nepomuk stuff breaks the kdebase build for me. In particular it
expects the dbus xml files to be installed when building
workspace/lib/nepomukqueryclient. The problem is that it thinks that its
building the workspace separately, which
On 05.09.08 21:33:09, Alexander Neundorf wrote:
On Sunday 24 August 2008, Pau Garcia i Quiles wrote:
Quoting Sune Vuorela [EMAIL PROTECTED]:
On Sunday 24 August 2008 23:25:03 Mike Arthur wrote:
In my experience using CPack however I'm pretty sure we could get the
package generators in
On 27.08.08 10:58:25, Matthew Woehlke wrote:
Andreas Pakulat wrote:
On 26.08.08 18:32:18, Matthew Woehlke wrote:
Forwarding to kde-buildsystem for a more official opinion.
And where is the original discussion?
http://permalink.gmane.org/gmane.comp.kde.devel.koffice/15364
The bits
On 26.08.08 18:32:18, Matthew Woehlke wrote:
Forwarding to kde-buildsystem for a more official opinion.
And where is the original discussion? The bits you posted are pretty
meaningless to me, whats the problem?
Andreas
--
You will be Told about it Tomorrow. Go Home and Prepare Thyself.
On 24.08.08 18:46:18, Brad Hards wrote:
I'm planning to add a feature that depends on a particular feature in Qt 4.5.
Obviously I don't want to break current compilation with Qt 4.5
Should I write a specific test for the required class, or can I just work off
the Qt version?
I think that
On 17.08.08 01:38:25, Alexander Neundorf wrote:
On Saturday 16 August 2008, Andreas Pakulat wrote:
On 15.08.08 21:56:42, Alexander Neundorf wrote:
On Friday 15 August 2008, Andreas Pakulat wrote:
On 15.08.08 00:13:49, Alexander Neundorf wrote:
Con:
-with the patch there are now
On 15.08.08 00:13:49, Alexander Neundorf wrote:
On Thursday 07 August 2008, Andreas Pakulat wrote:
On 07.08.08 22:11:11, Thiago Macieira wrote:
Andreas Pakulat wrote:
This has a problem, I can't depend on KDE 4.2.0 until its released and
hence modules in trunk/ cannot have a dependency
On 15.08.08 21:56:42, Alexander Neundorf wrote:
On Friday 15 August 2008, Andreas Pakulat wrote:
On 15.08.08 00:13:49, Alexander Neundorf wrote:
On Thursday 07 August 2008, Andreas Pakulat wrote:
On 07.08.08 22:11:11, Thiago Macieira wrote:
Andreas Pakulat wrote:
This has
On 07.08.08 19:59:52, Thiago Macieira wrote:
Andreas Pakulat wrote:
Hi,
since we require Cmake 2.6 now I think we should support CMake's
integrated way of version-checking. CMake 2.6 supports this:
find_package(KDE4 4.2.0)
and I'm proposing the attached patch to make this work
On 07.08.08 21:32:32, Thiago Macieira wrote:
Andreas Pakulat wrote:
On 07.08.08 19:59:52, Thiago Macieira wrote:
Andreas Pakulat wrote:
Hi,
since we require Cmake 2.6 now I think we should support CMake's
integrated way of version-checking. CMake 2.6 supports this:
find_package
On 07.08.08 22:11:11, Thiago Macieira wrote:
Andreas Pakulat wrote:
On 07.08.08 21:32:32, Thiago Macieira wrote:
Andreas Pakulat wrote:
On 07.08.08 19:59:52, Thiago Macieira wrote:
Andreas Pakulat wrote:
Hi,
since we require Cmake 2.6 now I think we should support CMake's
On 05.08.08 02:02:21, Alexander Neundorf wrote:
On Saturday 19 July 2008, Andreas Pakulat wrote:
On 19.07.08 10:28:41, Alexander Neundorf wrote:
On Saturday 19 July 2008, Andreas Pakulat wrote:
...
and more importantly make Debugfull work with CMake 2.6. As I didn't
find
On 05.08.08 00:03:37, Alexander Neundorf wrote:
On Monday 04 August 2008, Andreas Pakulat wrote:
Hi,
I hope the subject doesn't stir up a flame-war. I'm not questioning the
dependency. My question is: Shouldn't FindKdepimLibs.cmake be requiring
Boost? There's currently breakage
On 05.08.08 10:28:12, Allen Winter wrote:
On Tuesday 05 August 2008 10:12:27 Thiago Macieira wrote:
On Tuesday 05 August 2008 15:33:07 Allen Winter wrote:
On Monday 04 August 2008 16:53:19 Andreas Pakulat wrote:
Hi,
I hope the subject doesn't stir up a flame-war. I'm
Hi,
I hope the subject doesn't stir up a flame-war. I'm not questioning the
dependency. My question is: Shouldn't FindKdepimLibs.cmake be requiring
Boost? There's currently breakage in the 4.1 branch (kdeplasma-addons)
because one part of the comic dataengine in there uses libsyndication
from
Hi,
I just noticed that FindKDE4Internal doesn't put the flags it sets for
the various buildtypes into the cache. This means the cache will contain
the standard variables from CMake instead. I'm wondering wether we
should put our own flags into the cache instead. It currently doesn't
seem to be
On 23.07.08 16:14:30, Allen Winter wrote:
I need help from the CMake Gurus.
Attached is my attempt at rewriting kdepim/akonadi/agents/nie/CMakeLists.txt.
The problem is: the nepomuk-rcgen program creates a file that contains a list
of source files to compile into the nie library.
So
On 23.07.08 16:42:15, Allen Winter wrote:
On Wednesday 23 July 2008 16:38:09 Andreas Pakulat wrote:
On 23.07.08 16:14:30, Allen Winter wrote:
I need help from the CMake Gurus.
Attached is my attempt at rewriting
kdepim/akonadi/agents/nie/CMakeLists.txt.
The problem
On 23.07.08 16:14:30, Allen Winter wrote:
I need help from the CMake Gurus.
Attached is my attempt at rewriting kdepim/akonadi/agents/nie/CMakeLists.txt.
The problem is: the nepomuk-rcgen program creates a file that contains a list
of source files to compile into the nie library.
So
On 19.07.08 10:28:41, Alexander Neundorf wrote:
On Saturday 19 July 2008, Andreas Pakulat wrote:
...
and more importantly make Debugfull work with CMake 2.6. As I didn't
find a reference of CMAKE_CONFIGURATION_TYPES for cmake 2.4 I've set it
only for 2.6. Please can you have a look
On 18.07.08 18:26:58, Thiago Macieira wrote:
Andreas Pakulat wrote:
Damn, actually I have a slight feeling I've asked this already. Any
objections against putting this information close to the gcc-version of
setting the flags. So neither I nor anybody else need to ask stupid
questions again
On 18.07.08 23:06:50, Alexander Neundorf wrote:
On Friday 18 July 2008, Thiago Macieira wrote:
Alexander Neundorf wrote:
On Friday 18 July 2008, Andreas Pakulat wrote:
Hi,
Whats the reasoning behind using -O2 in the Debug CXX flags? A debug
build shouldn't use _any_ optimizations
On 11.07.08 16:29:56, Helio Chissini de Castro wrote:
On Thursday 10 July 2008 17:48:41 Andreas Pakulat wrote:
What does CMakeCache.txt say about boost? Whats the error message?
Error
On 10.07.08 15:02:15, Helio Chissini de Castro wrote:
On Friday 04 July 2008 14:43:29 Andreas Pakulat wrote:
On 04.07.08 13:25:55, Thiago Macieira wrote:
David Faure wrote:
On Friday 04 July 2008, Thiago Macieira wrote:
Andreas Pakulat wrote:
I want to change this. Is it o. k
101 - 200 of 277 matches
Mail list logo
