On Mon, Apr 14, 2008 at 6:05 PM, Brad King <[EMAIL PROTECTED]> wrote:
> I've updated the documentation accordingly.
>
> I've also committed a fix that should make the old code continue to run
> (and use the RUNTIME destination). I added a new policy CMP0006 that
> will warn about not providin
Quoting Dirk Mueller <[EMAIL PROTECTED]>:
> On Friday 11 April 2008, Thiago Macieira wrote:
>
>> > Yet GENERIC_LIB_SOVERSION is just set to "4". I miss something,
>> > obviously.
>> ELF doesn't support that. It should support two numbers: the minimum
>> version and the current. That is, kdelibs 4.
Dirk Mueller wrote:
>On Friday 11 April 2008, Thiago Macieira wrote:
>> > Yet GENERIC_LIB_SOVERSION is just set to "4". I miss something,
>> > obviously.
>>
>> ELF doesn't support that. It should support two numbers: the minimum
>> version and the current. That is, kdelibs 4.1 is backwards compatib
On Friday 11 April 2008, Thiago Macieira wrote:
> > Yet GENERIC_LIB_SOVERSION is just set to "4". I miss something,
> > obviously.
> ELF doesn't support that. It should support two numbers: the minimum
> version and the current. That is, kdelibs 4.1 is backwards compatible with
> 4.0; Qt 4.4 is ba
Benjamin Reed wrote:
> I'm getting even more confused then... "RUNTIME" means executables in
> this context, doesn't it? Then maybe I was wrong in my assessment of
> what "BUNDLE" means in the install command in the first place... does
> it mean loadable modules (.bundle) or does it mean app-bund
Hi,
so today I found that there are actually problems with cmake 2.6 and
dependency scanning.
a) after changing an installed header the .moc files for headers that
include the updated header are not re-generated which might cause
problems when you do ABI changes (like removing a method) on the
in
On Mon, Apr 14, 2008 at 5:08 PM, Brad King <[EMAIL PROTECTED]> wrote:
> I guess no one has been using CMake from CVS on the mac. This has been
> broken since Aug 22 2007:
>
>
> http://www.cmake.org/cgi-bin/viewcvs.cgi/Source/cmInstallCommand.cxx?root=CMake&r1=1.26&r2=1.27
Nope, when trying t
Benjamin Reed wrote:
> On Mon, Apr 14, 2008 at 4:11 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
>> add_executable(hello MACOSX_BUNDLE main.cpp)
>> install(TARGETS hello RUNTIME DESTINATION bin
>> LIBRARY DESTINATION lib
>> ARCHIVE DESTINATION lib)
On Mon, Apr 14, 2008 at 4:11 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> Ok, we really should get nightly builds for the more "exotic" platforms (OSX,
> FreeBSD, Solaris, Windows).
Yeah. What do I need to do this? Dirk's build script stuff seems
pretty opaque to me, and the KDE dashbo
On Monday 14 April 2008, Michael Druing wrote:
> Please keep in mind that gold is ELF-only, so it cannot be used to link on
> Win32.
>
> Thus, linking KDE with gold must stay an option and shouldn't become the
Yes, of course.
Alex
___
Kde-buildsystem ma
On Monday 14 April 2008, Andreas Hartmetz wrote:
> Hi all,
>
> I am one of the few KDEers who tried to link KDE4 using the upcoming linker
> in GNU binutils called "gold". gold fails if it encounters an unimplemented
> option (I guess it should ignore some less important ones instead) and it
> seem
On Monday 14 April 2008, Benjamin Reed wrote:
> I've not had a chance to do any building of KDE stuff for a month or
> so, and I'm trying to get caught up. I've installed the latest CMake
> release candidate (2.6.0-rc8) and have started building, and it looks
> like something deep in our macros ha
Allen Winter wrote:
> On Monday 14 April 2008 13:19:18 Brad King wrote:
>>FindAkode.cmake
> I see CACHE INTERNAL in FindAkode.cmake. Isn't that ok?
It will work, but there is no reason to be in the cache. The variable
being set is just summarizing results for the project.
>>FindGettex
On Monday 14 April 2008 13:19:18 Brad King wrote:
> Hi Folks,
>
> I just noticed that these files in kdelibs/cmake/modules:
>
>FindAkode.cmake
I see CACHE INTERNAL in FindAkode.cmake. Isn't that ok?
>FindFreetype.cmake
Fix committed.
>FindGettext.cmake
I see CACHE FILEPATH in FindGe
Brad King wrote:
> Dirk Mueller wrote:
>> I've switched to cmake 2.6 for dashbot
>> (http://ktown.kde.org/~dirk/dashboard/). The problem I have now is this:
>>
>> CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE):
>> file CHRPATH could not write new RPATH "/opt/testing/lib" to the file
Benjamin Reed schrieb:
> I've not had a chance to do any building of KDE stuff for a month or
> so, and I'm trying to get caught up. I've installed the latest CMake
> release candidate (2.6.0-rc8) and have started building, and it looks
> like something deep in our macros has changed recently, I'm
I've not had a chance to do any building of KDE stuff for a month or
so, and I'm trying to get caught up. I've installed the latest CMake
release candidate (2.6.0-rc8) and have started building, and it looks
like something deep in our macros has changed recently, I'm now unable
to build basically
Dirk Mueller wrote:
> I've switched to cmake 2.6 for dashbot
> (http://ktown.kde.org/~dirk/dashboard/). The problem I have now is this:
>
> CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE):
> file CHRPATH could not write new RPATH "/opt/testing/lib" to the file
> "/var/tmp/kdelibs-
Hi Folks,
I just noticed that these files in kdelibs/cmake/modules:
FindAkode.cmake
FindFreetype.cmake
FindGettext.cmake
FindOpenEXR.cmake
FindOpenEXR.cmake
FindPCRE.cmake
contain lines like
set(PCRE_LIBRARIES ${PCRE_PCRE_LIBRARY} ${PCRE_PCREPOSIX_LIBRARY}
CACHE STRING "Th
Dirk Mueller wrote:
> On Monday 14 April 2008, Brad King wrote:
>
>> CMake 2.6 comes with an ELF binary parser. It is used to change the
>> RPATH or RUNPATH of an existing binary before installation. This is
>> much faster than relinking with a new RPATH as was done by CMake 2.4
>> (relinking is
On Monday 14 April 2008, Brad King wrote:
> CMake 2.6 comes with an ELF binary parser. It is used to change the
> RPATH or RUNPATH of an existing binary before installation. This is
> much faster than relinking with a new RPATH as was done by CMake 2.4
> (relinking is still used on non-ELF syste
Brad King wrote:
>> By the way, this is not the first I've heard of this error. Other
>> people have run into it.
>
>Okay, but no one ever reported it to our bug tracker so I didn't know.
Yeah, I didn't hear from the first person either. He had just upgraded to
2.6 and was going to clean up and b
Thiago Macieira wrote:
> Brad King wrote:
>>> CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE):
>>> file CHRPATH could not write new RPATH "/opt/testing/lib" to the
>>> file "/var/tmp/kdelibs-796689-build/opt/testing/bin/kde4automoc": No
>>> valid ELF RPATH entry exists in the file;
>>
Brad King wrote:
>> CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE):
>> file CHRPATH could not write new RPATH "/opt/testing/lib" to the
>> file "/var/tmp/kdelibs-796689-build/opt/testing/bin/kde4automoc": No
>> valid ELF RPATH entry exists in the file;
>
>CMake 2.6 comes with an ELF b
Dirk Mueller wrote:
> I've switched to cmake 2.6 for dashbot
> (http://ktown.kde.org/~dirk/dashboard/). The problem I have now is this:
>
> CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE):
> file CHRPATH could not write new RPATH "/opt/testing/lib" to the file
> "/var/tmp/kdelibs-
Hi,
I've switched to cmake 2.6 for dashbot
(http://ktown.kde.org/~dirk/dashboard/). The problem I have now is this:
CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE):
file CHRPATH could not write new RPATH "/opt/testing/lib" to the file
"/var/tmp/kdelibs-796689-build/opt/testing/
Quoting Dirk Mueller <[EMAIL PROTECTED]>:
This thread was originally posted by me (wrongly) on kde-buildsystem@
instead of kde-packager@, see
http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/3127 for the
top of the thread.
> On Thursday 03 April 2008, Pau Garcia i Quiles wrote:
>
>>
On Monday 14 April 2008, Michael Druing wrote:
> Please keep in mind that gold is ELF-only, so it cannot be used to link on
> Win32.
>
> Thus, linking KDE with gold must stay an option and shouldn't become the
> default (at least until other binary formats are implemented in gold)
I believe that l
On Thursday 03 April 2008, Pau Garcia i Quiles wrote:
> - they keep packaging as they have done until now, as if CPack 2.6
> cannot properly package .deb and .rpm
do I understand it correctly that cpack only generates src.rpms? or does it
create binary rpms?
the mailing list for packagers is [E
29 matches
Mail list logo
