GZipping files at build time
Hello Build System Experts, Within the KDEGames project we would like to gzip compress some files at build-time, and I am coming to you folks for suggestions. Can CMake do this for us? (I don't think so, but I'm not certain. Maybe CPack?) Is any other part of KDE currently gzipping at build-time? If so, can we reuse this solution? The obvious approach is to add a build-time dependency on the gzip executable, but this might be a pain on non-Unix platforms. Of course, there are lots of other tools out there than can do gzip compression. Are there any that we already have as a dependency? Or that might be easier to distribute? Whatever the actual compression solution, we'll also need to package it up in a convenient CMake macro, as the functionality is needed in lots of (soon to be) separate applications. Since I'm no CMake whiz, I'll probably need help with that part, too. :) Thanks for your thoughts, Parker ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: hidden visibility
On domingo, 19 de fevereiro de 2012 23.50.49, Raphael Kubo da Costa wrote: Stephen Kelly steve...@gmail.com writes: For KDE Frameworks 5, gcc 4.2 is too old. Qt5 requires a much more recent version (I don't recall which exactly). Unfortunately I'm a bit behind in the Qt5 discussions and development. I tried to look for something about this in wiki.qt-project.org and JIRA (searching in Gmane isn't working very well at the moment) but couldn't find anything. Can you point to any discussion about the issue? AFAIU, Apple still ships gcc 4.2.1 (the last GPLv2 version of gcc) with its OS; does it mean another compiler is going to be required for OS X users too? Qt supports gcc 4.2.1 because that's what Apple supports. Unfortunately. But eventually we'll drop that once Apple moves on. And to be honest, I'd rather not support it anywhere but on Mac OS X. The BSDs can upgrade to more recent versions of GCC and I'd recommend something released in the past 2 or at most 3 years. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: GZipping files at build time
On 19.02.12 22:36:47, Parker Coates wrote: Hello Build System Experts, Within the KDEGames project we would like to gzip compress some files at build-time, and I am coming to you folks for suggestions. Can CMake do this for us? Yes it can, using a custom command. KDevPlatform provides a macro that uses this to zip up application-template directories: https://projects.kde.org/projects/extragear/kdevelop/kdevplatform/repository/revisions/master/entry/cmake/modules/KDevPlatformMacros.cmake That macro basically zips up a directory. The downside of it currently is that it requires manual cmake-re-run when the directory contents change. This could be fixed by replacing the foreach-loop and the file(GLOB) with manually listing the files. The script currently depends on zip or tar being in PATH, but this hasn't been a problem for us so far. Andreas ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: hidden visibility
Thiago Macieira thi...@kde.org writes: On domingo, 19 de fevereiro de 2012 23.50.49, Raphael Kubo da Costa wrote: AFAIU, Apple still ships gcc 4.2.1 (the last GPLv2 version of gcc) with its OS; does it mean another compiler is going to be required for OS X users too? Qt supports gcc 4.2.1 because that's what Apple supports. Unfortunately. But eventually we'll drop that once Apple moves on. And to be honest, I'd rather not support it anywhere but on Mac OS X. The BSDs can upgrade to more recent versions of GCC and I'd recommend something released in the past 2 or at most 3 years. Dropping support for ancient gcc's should hopefully happen by the time clang becomes the default compiler on FreeBSD :-) On the e-c-m/KF5 side, it'd be good to follow Qt and keep those gcc 4.2 checks as long as Qt itself also supports it. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Strange commit to FindKDE4Internal.cmake
On 2/19/2012 5:53 PM, Pau Garcia i Quiles wrote: On Sun, Feb 19, 2012 at 11:12 PM, Stephen Kellysteve...@gmail.com wrote: How would FindFoo.cmake know where to look? Exactly like it does know now: trial and error looking for the most common places. If it does not find the headers, libraries, etc, then it will report an error and the user will use cmake-gui to browse for the appropriate files/directories. Windows users are used to this. If relaying on a LibFooConfig.cmake, find_package will fail saying it didn't even find LibFooConfig.cmake, which is much worse IMHO. How is that different? In the Find module case the user needs to set FOO_INCLUDE_DIR for foo.h, FOO_LIBRARY for foo.lib, and perhaps others. In the package Config case the user needs only to set *one* FOO_DIR value to the location of a single file. Furthermore the find_package config mode already searches in the common prefixes for the package configuration file just like the find_library and find_path commands used in Find modules. On the CMake dev list we're currently discussing how to make the error message clearer when it is not found. Much of the trouble with it IMO is that it mentions the Find module case even when searching for a package Config file. Note that since CMake 2.8.5 we support a package registry: http://www.cmake.org/Wiki/CMake/Tutorials/Package_Registry so packages can be found even if their installers go to a random place so long as the installers populate the registry. Brad on the CMake list suggested that such files would belong in the documentation of libfoo (libfoo-doc package), which I thought was an interesting point (Or in any other documentation it could be a snippet). That's what I proposed at the beginning Great, then we agree. think it should be added to a /usr/share/cmake/Modules-like directory. But that place is *only* for official 3rd-party modules, not for, say, a libpng module provided by KDE. I also pointed out in the CMake list thread Stephen mentioned that there is no reason to even have a Find module for a CMake-aware package except to tweak find_package's search for the package configuration file (FooConfig.cmake). Even then it belongs in the -doc package. Even if a package upstream does not build with CMake it is still possible for it to provide a package configuration file for find_package to use, just like many projects provide pkgconfig .pc files. Stephen is doing this for Qt5 AFAIK. If a package upstream is not CMake-aware then the Find module should be contributed to CMake upstream. Otherwise there is no official Find module available from either CMake or the package upstream so it would not belong in your proposed official 3rd-party Modules directory anyway. If installed with the -dev package (even as a reference implementation or a template), it's kind of back to the situation of putting the treasure map with the treasure. I disagree. If it comes with the -dev package people think they should find and load it from there which as Stephen suggested is putting a treasure map with the treasure. If it comes with the -doc package then the documentation can tell them to put it in their project. Installing FindLibFoo.cmake with the -dev package means you a CMake module coming from the best possible author: upstream itself. This will still be the case if it comes with the -doc package. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: hidden visibility
On Monday 20 February 2012, Raphael Kubo da Costa wrote: Thiago Macieira thi...@kde.org writes: On domingo, 19 de fevereiro de 2012 23.50.49, Raphael Kubo da Costa wrote: AFAIU, Apple still ships gcc 4.2.1 (the last GPLv2 version of gcc) with its OS; does it mean another compiler is going to be required for OS X users too? Qt supports gcc 4.2.1 because that's what Apple supports. Unfortunately. But eventually we'll drop that once Apple moves on. And to be honest, I'd rather not support it anywhere but on Mac OS X. The BSDs can upgrade to more recent versions of GCC and I'd recommend something released in the past 2 or at most 3 years. Dropping support for ancient gcc's should hopefully happen by the time clang becomes the default compiler on FreeBSD :-) On the e-c-m/KF5 side, it'd be good to follow Qt and keep those gcc 4.2 checks as long as Qt itself also supports it. So we could limit it to = 4.2 at least. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: GZipping files at build time
On Monday 20 February 2012, Parker Coates wrote: Hello Build System Experts, Within the KDEGames project we would like to gzip compress some files at build-time, and I am coming to you folks for suggestions. Can CMake do this for us? (I don't think so, but I'm not certain. Maybe CPack?) Is any other part of KDE currently gzipping at build-time? If so, can we reuse this solution? What do you want to compress ? Just individual files or directories or ? The obvious approach is to add a build-time dependency on the gzip executable, but this might be a pain on non-Unix platforms. Of course, Try cmake -E tar ... This exists for this purpose. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Strange commit to FindKDE4Internal.cmake
On Sunday 19 February 2012, Pau Garcia i Quiles wrote: On Sun, Feb 19, 2012 at 11:41 PM, Ralf Habacker ralf.habac...@googlemail.com wrote: There is a linux rpm package installing about 150 Find... scripts into /usr/share/cmake-2.8/modules (the package is named cmake) and a 3rdparty library rpm package installing a dedicated Find... script into the same location (or a well known 3rdparty location) because the related Find. script is not in the cmake binary package ? Is this forbidden ? On Debian, this is considered a bug. Really. Is the library package maintainer be forced to add his Findlib... script to the official cmake release or to a dedicated extra-cmake-find-script-repository and tell the user to install an additional dependency ? The library package maintainer must only add this Findlib... to the library package. He needs not write anything new or look for Findlib... anywhere else. If the original source tarball (i. e. upstream) includes Findlib..., then it will be installed in /usr/share/doc/libfoo-dev/cmake. And when his Find... script is not accepted by the cmake maintainers for whatever reasons, I never mentioned this Find... script would ever be submitted to CMake maintainers. It should not. Well, that's what we are doing since kdelibs 4.0 and it works very well for us. CMake ships a very small FindKDE4.cmake, which searches for our lengthy FindKDE4Internal.cmake, which when found, does the rest. The FindKDE4Internal.cmake is quite similar to a KDE4Config.cmake file, but this mechanism didn't exist yet back then, I think it was added in 2.6.0. So, in general, yes, upstreaming a Find-module to cmake is a good thing. The whole idea of the Config.cmake files is more or less to get rid of Find- modules, to get rid of the need to have a lot of information about Foo outside Foo (because Foo provides all the information in its config file). While I understand the idea behind your suggestion to first search for Config.cmake files, and if not found, fall back to Find-module, this doesn't improve the situation in the error case, and also it shouldn't be necessary. If a package installs a config file, you should (IMO) call find_package with the NO_MODULE parameter: find_package(Foo NO_MODULE). If you think this is not good enough for finding it, you can add additional paths where to look: find_package(Foo NO_MODULE PATHS /opt/kde4 c:/mystuff ) If you think this shouldn't be in a users CMakeLists.txt, but in a Find- module, I agree. Then the CMakeLists.txt would be: find_package(Foo) and FindFoo.cmake would be: find_package(Foo NO_MODULE PATHS /opt/kde4 c:/mystuff ) find_package_handle_standard_args(Foo CONFIG_MODE) which is basically trivial and additional gives a nice and brief error/success message thanks to fphsa() From the two error messages I posted earlier, the one which talks about the missing Find-module, is directed at the developers of the package. It could be reworded less lengthy and less friendly: Could not find FindFoo.cmake Your buildsystem is broken, fix it ! No user should ever see this. Users should only see: Could not find FooConfig.cmake file. Adjust CMAKE_PREFIX_PATH to find it. or the brief summary from find_package_handle_standard_args(): Found Foo (/usr/lib/cmake/FooConfig.cmake) OR Did not find Foo (neither FooConfig.cmake nor foo-config.cmake) OR the normal messages: Found Foo (/usr/lib/libfoo.so) Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: extra-cmake-modules installs into versionned dir
On Saturday 18 February 2012 18:45:54 Alexander Neundorf wrote: On Saturday 18 February 2012, David Faure wrote: Can we PLEASE get rid of the version number in the install directory? It's way more trouble than any benefit it might bring. If one day we want co-installable incompatible releases, I want to have co-installable releases right from the beginning. I don't. It makes no sense what so ever to have it, and it is only giving headaches to the users of ecm. /Sune -- Genius, I cannot boot the IRC directory, how does it work? You never have to enable a DLL pin in order to debug the mouse of the hardware. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Strange commit to FindKDE4Internal.cmake
Hello, On pirmadienis 20 Vasaris 2012 22:50:46 Alexander Neundorf wrote: that project installs its find-module into /usr/share/cmake/modules - at least the debian package does. This is wrong. Emm no, Debian package installs to /usr/share/cmake/SharedDesktopOntologies/ (*Config.cmake file) [1] [1] http://packages.debian.org/sid/all/shared-desktop-ontologies/filelist -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
