Re: RFC: A Configure Wrapper
Am Sonntag 02 Juli 2006 07:25 schrieb Stephan Kulow: Am Sonntag, 2. Juli 2006 06:08 schrieb Michael Pyne: It sounds useful to me if it does nothing more than transform --prefix=foo and --disable-debug to the CMake equivalents. And I don't see a reason to force people to have to read CMake documentation when ./configure make make install works for 95% of the other software out there. Yeah, but for KDE it will be ./configure cd build make make install So we already have the first difference you have to read about. And if you're there, you can just as well go the full route. I'd vote against the introduction of this placebo script. I'd rather add a configure script that will output the cmake command to call. So if you go ./configure --prefix /usr, it will say KDE does not use autoconf anymore, next time use cmake -D... (and I do have to admit I don't know the exact D options, --prefix is easier :) Yes, this sounds good. Here's the intro: http://wiki.kde.org/tiki-index.php?page=KDECMakeIntro#id140643 Bye Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Poppler-qt4
Am Donnerstag, 29. Juni 2006 23:18 schrieb Pino Toscano: Alle 22:06, giovedì 29 giugno 2006, Wilfried Huss ha scritto: Besides, okular's fork of the DVI code has thrown away 9 years of commit history. This is also a problem. I thougt KDE switched to SVN so that such things would not happen again. Now the files are really copied, and no history is lost. Luckly SVN is smart enough. Thank, you. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
current usage of GNUWIN32
Hi, finally I had a look again at how GNUWIN32 is used in kdelibs. Am I right that it has been removed from all cmake modules and is now just used in the toplevel CMakeLists.txt by calling FIND_PACKAGE(GNUWIN32) ? If that's the case, maybe this should be moved into FindKDE4Internal.cmake. Any objections ? Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RFC: A Configure Wrapper
On Saturday 01 July 2006 18:35, Matt Rogers wrote: On Saturday 01 July 2006 21:39, Allen Winter wrote: Howdy, Attached is a perl script that emulates the old configure program. Pretty straightforward so I don't think you need to be a perl expert to understand it. It only supports a minimum set of the old options. More options can be easily added if there is a CMake equivalent. So far it supports these options: --prefix --enable-debug=yes|no|full --enable-final --disable-rpath --with-qt-dir=DIR You'll also notice that it creates a build subdir and runs cmake from within that subdir. So, the idea is that users not willing to learn the new cmake-way will run: % ./configure options; cd builddir; make make install And, unfortunately, this script will need to be kept in sync with what's happening in the cmake-stuff, and also each module will need their own copy. Comments? More configure options to add? -Allen Do we really need this? Nope. People should just learn the cmake way IMHO. I think so too. With the use of the 'ccmake' program, it's almost easier than running configure. Probably true. This is just another unneeded maintainence burden IMHO. Absolutely. Surely developers aren't that lazy that they can't take the 5 seconds to read a quick start guide that says: I would hope not. Do we have such a guide already? It would also contain other information on CMake, of course. If not, I'll volunteer to write it. We have a wiki. I'd like to see the INSTALL file at the top of each module updated. Would you take on that job? We also need a nice doc at developer.kde.org. The wiki page should probably be turned into a howto type page at d.k.o. I wrote the configure perl wrapper because: 1. it was on my todo list -- and it was a fun diversion (I occasionally like to write perl) 2. it seemed like a good thing to provide the distributions and non-developers Saying that...I would rather not have it... it will be a major pain to keep up-to-date. So, the consensus is to change the script to not actually run cmake, but instead print: KDE no longer supports the autotools build change. Please run: cmake -D... ?? -- Let's Keep the Political Talk Out of KDE PLEASE ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RFC: A Configure Wrapper
On Sunday 02 July 2006 08:04, Allen Winter wrote: On Saturday 01 July 2006 18:35, Matt Rogers wrote: On Saturday 01 July 2006 21:39, Allen Winter wrote: Howdy, Attached is a perl script that emulates the old configure program. Pretty straightforward so I don't think you need to be a perl expert to understand it. It only supports a minimum set of the old options. More options can be easily added if there is a CMake equivalent. So far it supports these options: --prefix --enable-debug=yes|no|full --enable-final --disable-rpath --with-qt-dir=DIR You'll also notice that it creates a build subdir and runs cmake from within that subdir. So, the idea is that users not willing to learn the new cmake-way will run: % ./configure options; cd builddir; make make install And, unfortunately, this script will need to be kept in sync with what's happening in the cmake-stuff, and also each module will need their own copy. Comments? More configure options to add? -Allen Do we really need this? Nope. People should just learn the cmake way IMHO. I think so too. With the use of the 'ccmake' program, it's almost easier than running configure. Probably true. This is just another unneeded maintainence burden IMHO. Absolutely. Surely developers aren't that lazy that they can't take the 5 seconds to read a quick start guide that says: I would hope not. Do we have such a guide already? It would also contain other information on CMake, of course. If not, I'll volunteer to write it. We have a wiki. I'd like to see the INSTALL file at the top of each module updated. Would you take on that job? We also need a nice doc at developer.kde.org. The wiki page should probably be turned into a howto type page at d.k.o. I've added the INSTALL updates and the doc for dev.k.o to my TODO list. I wrote the configure perl wrapper because: 1. it was on my todo list -- and it was a fun diversion (I occasionally like to write perl) 2. it seemed like a good thing to provide the distributions and non-developers Saying that...I would rather not have it... it will be a major pain to keep up-to-date. So, the consensus is to change the script to not actually run cmake, but instead print: KDE no longer supports the autotools build change. Please run: cmake -D... ?? Yes, I believe that is the consensus. -- Matt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [Kde-dashboard] Broken continuous build for KDE imac-x86.befunk.com/i386-Apple-MacOSX-10.4-gcc4.0
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 failures are now valid again. :) ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
