[cmake-developers] GenerateExportHeader macro in CMake?

2011-07-13 Thread Stephen Kelly
Hi, I've been working on my GenerateExportHeader macro described here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/36664 The result is here: https://gitorious.org/~steveire/cmake/steveires- cmake/commit/a80318ae6a299f44de8597d4ee705278554b7a4a The problem is that the unit

[cmake-developers] Test for compiler flags ineffective with xlc?

2011-08-11 Thread Stephen Kelly
Hi, In this build log the test for -fvisibility=hidden results in success, but when the flag is used it fails: http://www.cdash.org/CDash/testDetails.php?test=109109951build=1419259 I'm guessing that compiler treats -ffoo as a filename for some reason. Can anything be done about that? Should

Re: [cmake-developers] GenerateExportHeader macro in CMake?

2011-08-23 Thread Stephen Kelly
David Cole wrote: Hi Stephen, So... this topic is in 'next', and today, it only fails on 4 dashboards in total. I will try to get output for you on the wcl (Watcom) compiler dashboard -- since it timed out, there is no test output reported on CDash...

Re: [cmake-developers] GenerateExportHeader macro in CMake?

2011-08-24 Thread Stephen Kelly
Stephen Kelly wrote: Yep, I've just had a look and possibily fixed the Intel and HPUX cases. I did indeed fix the Intel and HPUX cases. The AIX one fails because the visibility test passes, because check_cxx_compiler_flag does not have a FAIL_REGEX for its warning: http://www.cdash.org

Re: [cmake-developers] GenerateExportHeader macro in CMake?

2011-08-24 Thread Stephen Kelly
David Cole wrote: The test itself passes on AIX, as seen here: http://www.cdash.org/CDash/testDetails.php?test=109727151build=1460504 It's only the particular machine that you pointed to that has problems. There are *several* tests that fail on that machine with the space in the path.

[cmake-developers] Freeze and review?

2011-09-05 Thread Stephen Kelly
Hi, I was wondering if stage/next is ever to be considered frozen around RC time, or is it always 'summer' in next? I have pushed a patch adding features from the KDE version of Qt4Macros.cmake to a branch in stage (qt_dbus_interface_args). As I don't maintain that file, should I contact the

Re: [cmake-developers] Freeze and review?

2011-09-05 Thread Stephen Kelly
. Thanks, Steve. Thanks, David On Mon, Sep 5, 2011 at 4:02 PM, Stephen Kelly steve...@gmail.com wrote: Hi, I was wondering if stage/next is ever to be considered frozen around RC time, or is it always 'summer' in next? I have pushed a patch adding features from the KDE version

Re: [cmake-developers] Automoc in cmake

2011-09-17 Thread Stephen Kelly
Stephen Kelly steveire@... writes: Alexander Neundorf wrote: Would it be possible to make CMAKE_AUTOMOC imply CMAKE_INCLUDE_CURRENT_DIR? All the best, Steve. Is it still possible to consider this? It's not ideal that you have to do this: set(CMAKE_AUTOMOC ON) set

[cmake-developers] An option to set LINK_INTERFACE_LIBRARIES to empty on all shared library targets?

2011-09-26 Thread Stephen Kelly
Hi, In KDE we set the LINK_INTERFACE_LIBRARIES to empty in a wrapper around add_library. The reason is to reduce the number of libraries which are linked to by default - developers have to be explicit about what is in the LINK_INTERFACE. I was considering patching CMake to do that by setting

Re: [cmake-developers] An option to set LINK_INTERFACE_LIBRARIES to empty on all shared library targets?

2011-09-26 Thread Stephen Kelly
Brad King wrote: On 9/26/2011 7:28 AM, Stephen Kelly wrote: In KDE we set the LINK_INTERFACE_LIBRARIES to empty in a wrapper around add_library. [snip] set(CMAKE_SET_LINK_INTERFACE_EMPTY ON) cause the LINK_INTERFACE to be empty for all shared library targets be accepted into CMake

Re: [cmake-developers] An option to set LINK_INTERFACE_LIBRARIES to empty on all shared library targets?

2011-10-01 Thread Stephen Kelly
Rolf Eike Beer wrote: The tricky part of this is to tell CMake to not enforce the implicit dependencies to be exported when creating an export file for targets created with this property enabled. Or better: to not enforce _any_ dependencies of a shared library to be exported then. I

Re: [cmake-developers] An option to set LINK_INTERFACE_LIBRARIES to empty on all shared library targets?

2011-10-01 Thread Stephen Kelly
Rolf Eike Beer wrote: Am Samstag 01 Oktober 2011, 13:57:09 schrieb Stephen Kelly: Rolf Eike Beer wrote: The tricky part of this is to tell CMake to not enforce the implicit dependencies to be exported when creating an export file for targets created with this property enabled

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-01 Thread Stephen Kelly
Hi David, This is related to my patch to set the link_interface_libraries to empty and to: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030 Quoting: Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted. By default, all libraries a target is linked

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-04 Thread Stephen Kelly
Stephen Kelly wrote: Hi David, This is related to my patch to set the link_interface_libraries to empty and to: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030 Quoting: Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted. By default, all

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-05 Thread Stephen Kelly
Brad King wrote: On 10/4/2011 10:22 PM, Stephen Kelly wrote: 1) Change the meaning of LINK_INTERFACE_LIBRARIES in set_target_properties(foo LINK_INTERFACE_LIBRARIES bar) Do you mean target_link_libraries, rather than set_target_properties? The latter is a very general command

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-06 Thread Stephen Kelly
Brad King wrote: On 10/5/2011 9:47 AM, Stephen Kelly wrote: Thanks for all of your explanations. It seems that introducing a way to do this with one command has some support. So if SOME_FEATURE is true, target_link_libraries(foo bar SOME_KEYWORD baz) if (SOME_FEATURE

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-06 Thread Stephen Kelly
Stephen Kelly wrote: Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE? Perhaps LINK AND LINK_ONLY? I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which are most clear to me. We can change it once we have an implementation to talk about. Well that didn't

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-06 Thread Stephen Kelly
Stephen Kelly wrote: target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork ) is equivalent to target_link_libraries(foo qtcore qtnetwork ) * foo will link against qtcore and qtnetwork I should have also noted that both qtcore and qtnetwork will also

Re: [cmake-developers] try_compile does not work for linker flags?

2011-10-07 Thread Stephen Kelly
Brad King wrote: On 10/7/2011 7:21 AM, Stephen Kelly wrote: I have a check for the Wl,--no-undefined flag in the test, and on some platforms the check passes (it seems), but the test fails later. Many linkers simply warn about an unused flag and ignore it. It's hard to test for them

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-07 Thread Stephen Kelly
Brad King wrote: On 10/6/2011 8:54 PM, Stephen Kelly wrote: Well that didn't take long. I pushed a target-link-libraries-interfaces branch to stage. Good start. Please change the three Doing*Interface modes into an enumeration so we don't have to worry about keeping three booleans

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-07 Thread Stephen Kelly
Bill Hoffman wrote: On 10/7/2011 11:30 AM, Brad King wrote: On 10/7/2011 11:23 AM, Stephen Kelly wrote: Brad King wrote: Good start. Please change the three Doing*Interface modes into an enumeration so we don't have to worry about keeping three booleans in a consistent state. Done. Also

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-07 Thread Stephen Kelly
Eric Noulard wrote: 2011/10/7 Stephen Kelly steve...@gmail.com: Bill Hoffman wrote: Please keep working on fixing the dashboard, there are a few style errors here: http://www.cdash.org/CDash/viewBuildError.php?buildid=1601031 -Bill Hmm, hadn't noticed those. The link doesn't show

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-07 Thread Stephen Kelly
Stephen Kelly wrote: such that kwtyle is run as a pre-commit hook. The instructions don't seem to work: Oops, they do work. I had missed the part about creating a new repo in my hooks dir. -- Powered by www.kitware.com Visit other Kitware open-source projects at http

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-07 Thread Stephen Kelly
Stephen Kelly wrote: Stephen Kelly wrote: such that kwtyle is run as a pre-commit hook. The instructions don't seem to work: Oops, they do work. I had missed the part about creating a new repo in my hooks dir. :/ Not finding some conf file: stephen@hal:~/dev/src/cmake{cmake

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-07 Thread Stephen Kelly
Stephen Kelly wrote: Stephen Kelly wrote: Stephen Kelly wrote: such that kwtyle is run as a pre-commit hook. The instructions don't seem to work: Oops, they do work. I had missed the part about creating a new repo in my hooks dir. :/ Not finding some conf file: I might

Re: [cmake-developers] try_compile does not work for linker flags?

2011-10-08 Thread Stephen Kelly
Brad King wrote: On 10/7/2011 7:21 AM, Stephen Kelly wrote: I have a check for the Wl,--no-undefined flag in the test, and on some platforms the check passes (it seems), but the test fails later. Many linkers simply warn about an unused flag and ignore it. It's hard to test for them

Re: [cmake-developers] Setting the link interface and dependencies in one command

2011-10-08 Thread Stephen Kelly
Bill Hoffman wrote: On 10/7/2011 11:30 AM, Brad King wrote: On 10/7/2011 11:23 AM, Stephen Kelly wrote: Brad King wrote: Good start. Please change the three Doing*Interface modes into an enumeration so we don't have to worry about keeping three booleans in a consistent state. Done. Also

Re: [cmake-developers] try_compile does not work for linker flags?

2011-10-10 Thread Stephen Kelly
Brad King wrote: On 10/8/2011 7:40 AM, Stephen Kelly wrote: Would it break anything if we changed check_cxx_compiler_flag to build a shared library instead of an executable? Maybe that will make the try_compile fail as expected. (I'll try add a test for that now) We cannot make a change

[cmake-developers] Apple tests for target_link_libraries failing

2011-10-11 Thread Stephen Kelly
Hi, I'm trying to find out why the target_link_libraries unit tests are failing on some platforms (but not mine...). I'm enabling one platform at a time. I enabled the failing tests for APPLE, so if you want to try it out, you need to comment out the if(APPLE).

Re: [cmake-developers] Apple tests for target_link_libraries failing

2011-10-11 Thread Stephen Kelly
Bill Hoffman wrote: On 10/11/2011 2:33 AM, Stephen Kelly wrote: Hi, I'm trying to find out why the target_link_libraries unit tests are failing on some platforms (but not mine...). I'm enabling one platform at a time. I enabled the failing tests for APPLE, so if you want to try it out

Re: [cmake-developers] Apple tests for target_link_libraries failing

2011-10-12 Thread Stephen Kelly
Bill Hoffman wrote: So, basically we this: set(CMAKE_LINK_INTERFACE_LIBRARIES ) add_library(libA SHARED classA.cpp) add_library(libB SHARED classB.cpp) add_library(libC SHARED classC.cpp) generate_export_header(libA) generate_export_header(libB) generate_export_header(libC)

Re: [cmake-developers] Apple tests for target_link_libraries failing

2011-10-13 Thread Stephen Kelly
Stephen Kelly wrote: The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. This is even more interesting now. http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094 On gentoo, the build

Re: [cmake-developers] Apple tests for target_link_libraries failing

2011-10-13 Thread Stephen Kelly
Rolf Eike Beer wrote: Stephen Kelly wrote: The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. This is even more interesting now. http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094

Re: [cmake-developers] Apple tests for target_link_libraries failing

2011-10-13 Thread Stephen Kelly
Rolf Eike Beer wrote: I'm not certain that's correct though. Those flags don't seem to be used when I build. I also don't know what those flags do. Linking CXX executable exec /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1

Re: [cmake-developers] Apple tests for target_link_libraries failing

2011-10-13 Thread Stephen Kelly
cmake_progress_start /home/rkw/test19-build/CMakeFiles 0 [rkw@Chameleon-12 ~/test19-build]$ On Oct 13, 2011, at 1:43 AM, Stephen Kelly wrote: On 10/12/2011 08:18 PM, Richard Wackerbarth wrote: Stephen, I'm not sure what you were expecting. The testing starts was with the version of test19

Re: [cmake-developers] Apple tests for target_link_libraries failing

2011-10-13 Thread Stephen Kelly
Stephen Kelly wrote: Ok, knowing why it fails on APPLE is good enough for me for now. The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. I was given access to a freebsd box to see why the build

Re: [cmake-developers] Apple tests for target_link_libraries failing

2011-10-13 Thread Stephen Kelly
Stephen Kelly wrote: Ok, knowing why it fails on APPLE is good enough for me for now. The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. I was given access to a freebsd box to see why the build

[cmake-developers] Keeping unit tests useful and splitting feature support from platform support

2011-10-16 Thread Stephen Kelly
Hi, I've been pushing some changes to the unit tests on the cmake-link-interface-libraries branch which is merged into next. Where the unit tests that I wrote were failing before in some cases, my changes make the dashboard go green again, but they don't actually make CMake any better. That

Re: [cmake-developers] Keeping unit tests useful and splitting feature support from platform support

2011-10-16 Thread Stephen Kelly
Rolf Eike Beer wrote: Stephen Kelly wrote: What I'd like to see is a distinction of feature support from platform support. In my case, I care about writing some features in cmake, but I don't care about watcom, GCC 3.3.1 etc. What I'd like to do is make sure my feature works on some

Re: [cmake-developers] Merging cmake-link-interface-libraries into master?

2011-10-19 Thread Stephen Kelly
Brad King wrote: On 10/19/2011 6:04 AM, Stephen Kelly wrote: I saw that the weekly merge of branches into master happened yesterday, but the cmake-link-interface-libraries branch didn't make the cut. Thanks for your work on this. So I'd like to know: 1) What made it not get merged? 2

Re: [cmake-developers] Merging cmake-link-interface-libraries into master?

2011-10-25 Thread Stephen Kelly
Brad King wrote: On 10/19/2011 11:14 AM, Stephen Kelly wrote: On 10/19/2011 6:04 AM, Stephen Kelly wrote: I saw that the weekly merge of branches into master happened yesterday, but the cmake-link-interface-libraries branch didn't make the cut. [snip] Not a major rush anyway. I'm still

Re: [cmake-developers] Merging cmake-link-interface-libraries into master?

2011-10-25 Thread Stephen Kelly
Brad King wrote: What does CMake think about rebasing? I much prefer to squash a branch like test-target_link_libraries into fewer commits so that eg adding newlines and changing tests to examine dashboard changes are not separate commits. I don't think those commits add value, but only

[cmake-developers] Installing Qt5Config.cmake from the Qt repo?

2011-10-28 Thread Stephen Kelly
for early objections before I start to do any work. Thanks, -- Stephen Kelly step...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions

Re: [cmake-developers] [Development] Installing Qt5Config.cmake from the Qt repo?

2011-10-28 Thread Stephen Kelly
On Friday, October 28, 2011 13:56:20 Thiago Macieira wrote: On Friday, 28 de October de 2011 13:13:20 Stephen Kelly wrote: * If you want to be easily found for others to depend on, you write a PackageConfig.cmake file and install it to a location CMake will use to find

Re: [cmake-developers] [Development] Installing Qt5Config.cmake from the Qt repo?

2011-10-28 Thread Stephen Kelly
templates using a bit of Perl (or whatever you want). For someone building a project which depends on Qt they would of course need CMake to find these files. Yep, I have nothing more to add to this. Thanks, -- Stephen Kelly step...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB

Re: [cmake-developers] [Development] Installing Qt5Config.cmake from the Qt repo?

2011-11-01 Thread Stephen Kelly
On Friday, October 28, 2011 07:58:25 Clinton Stimpson wrote: On Friday, October 28, 2011 06:21:23 am Stephen Kelly wrote: On Friday, October 28, 2011 13:56:20 Thiago Macieira wrote: On Friday, 28 de October de 2011 13:13:20 Stephen Kelly wrote: * If you want to be easily found for others

Re: [cmake-developers] [Development] Installing Qt5Config.cmake from the Qt repo?

2011-11-01 Thread Stephen Kelly
On Friday, October 28, 2011 13:13:20 Stephen Kelly wrote: == Summary == I'm considering adding some cmake files to Qt, which would be installed by Qt, and which would make it easier for CMake based projects to depend on Qt. I'm CC'ing the cmake developers too see what they think

Re: [cmake-developers] cmake automoc breaks kde

2011-11-02 Thread Stephen Kelly
On 11/02/2011 06:32 PM, David Faure wrote: On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote: No, it's the other way around, in KDE. $ grep Q_OBJECT kautosavefile.* kautosavefile.h: Q_OBJECT $ grep moc kautosavefile.cpp #include kautosavefile.moc If it did additionally other things,

Re: [cmake-developers] cmake automoc breaks kde

2011-11-02 Thread Stephen Kelly
On 11/02/2011 06:32 PM, David Faure wrote: #include foo.moc #include moc_foo.cpp This would have generated twice the same moc file, I think. IMO this is really confusing. Well there is no reason to include both, unless you have Q_OBJECT in the .cpp file too:-) I'm sure I've

[cmake-developers] Can't push to master directly

2011-11-04 Thread Stephen Kelly
] master - master (hook declined) error: failed to push some refs to 'g...@cmake.org:cmake.git' Does the wiki page need to have that section removed? Thanks, -- Stephen Kelly step...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30

Re: [cmake-developers] Can't push to master directly

2011-11-05 Thread Stephen Kelly
of the page confused me when I first started working with CMake git a few months ago, and I was looking at it again. Could it be an idea to split that page so that there is a page for people like me or new people which doesn't say anything about pushing to master? Thanks, -- Stephen Kelly step

[cmake-developers] target_include_directories branch in stage

2011-11-06 Thread Stephen Kelly
Hi, As discussed on the cmake user mailing list, I'm interesting in implementing the feature of target specific and configuration specific include directories. http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39114 I've pushed the target-include-directories branch

[cmake-developers] Should sucessive calls to find_package for one package succeed?

2011-11-06 Thread Stephen Kelly
Hi, Should successive calls to find_package succeed in general? Eg find_package(Grantlee COMPONENTS Templates) find_package(Grantlee COMPONENTS TextDocument) ? Currently if the target package uses Config files and install(TARGETS ... EXPORT) the convention is to use

Re: [cmake-developers] Should sucessive calls to find_package for one package succeed?

2011-11-07 Thread Stephen Kelly
Brad King wrote: On 11/6/2011 7:00 PM, Stephen Kelly wrote: include(${CMAKE_CURRENT_LIST_DIR}/GrantleeTargets.cmake) It is up to the author of the config file to block this correctly against multiple inclusion, e.g. if(NOT Grantlee_TARGETS_INCLUDED) set(Grantlee_TARGETS_INCLUDED 1

Re: [cmake-developers] Multiple dependent install(EXPORT) sets

2011-11-22 Thread Stephen Kelly
Brad King wrote: On 11/22/2011 9:31 AM, Stephen Kelly wrote: CMake Error: INSTALL(EXPORT twoDeps ...) includes target libtwo which requires target libone that is not in the export set. How can we resolve this? http://public.kitware.com/Bug/view.php?id=12588 Brad asked to bring this up

Re: [cmake-developers] cmake automoc breaks kde

2011-11-22 Thread Stephen Kelly
On 11/22/2011 06:20 PM, Alexander Neundorf wrote: Using Qt5 or Qt4 ? Qt4. There seems to be several problems: * KDE does include foo.moc if it wants the header file to be moc'd. This is 'incorrect' compared to what qmake expects, which would be a moc_foo.cpp include. Yes. * Some places

Re: [cmake-developers] Multiple dependent install(EXPORT) sets

2011-11-22 Thread Stephen Kelly
Alexander Neundorf wrote: On Tuesday 22 November 2011, Brad King wrote: On 11/22/2011 10:03 AM, Stephen Kelly wrote: Brad King wrote: We will have to require that the install(EXPORT) commands be invoked in dependency order (ex. A before B). That way when the command installing ExportB

Re: [cmake-developers] cmake automoc breaks kde

2011-11-22 Thread Stephen Kelly
On 11/22/2011 07:10 PM, Alexander Neundorf wrote: find #include (.*).moc - generate moc for \\1.cpp Was there a reason for preventing this? We can do that, but how can that work ? I mean, this will generate code for a class which is declated in a different source file, so it is unknown in

Re: [cmake-developers] cmake automoc breaks kde

2011-11-22 Thread Stephen Kelly
On 11/22/2011 07:37 PM, David Faure wrote: On Tuesday 22 November 2011 14:33:25 Stephen Kelly wrote: I think in many cases, fixing KDE will just be removing the explicit include foo.moc which is intended to run moc on foo.h, and let the automatic moc'ing do the work. No, to include

Re: [cmake-developers] cmake automoc breaks kde

2011-11-22 Thread Stephen Kelly
Alexander Neundorf wrote: Test added, works. What is not working right now is including someotherfile.moc. I could add special handling for including thisfile_p.moc (as opposed to moc_thisfile_p.cpp, which works). Yes, this is the issue that makes the build break in the frameworks branch.

Re: [cmake-developers] cmake automoc breaks kde

2011-11-22 Thread Stephen Kelly
On 11/22/2011 08:43 PM, Alexander Neundorf wrote: On Tuesday 22 November 2011, Stephen Kelly wrote: On 11/10/2011 10:16 PM, Alexander Neundorf wrote: ... Please give the RestoreAutmocKDECompatibility branch on cmake stage a try. It should work again, but print a warning if a file includes

Re: [cmake-developers] cmake automoc breaks kde

2011-11-22 Thread Stephen Kelly
On 11/22/2011 10:03 PM, Alexander Neundorf wrote: Now when I try to build the frameworks branch using the cmake next branch, I get: AUTOMOC: error: /home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The file includes the moc file kdirwatch_p.moc, which seems to be the moc file

[cmake-developers] Generating imported library targets without the cmake executable

2011-11-24 Thread Stephen Kelly
Hi there, I am working on installing CMake config files from the Qt repository so that there is less need for a FindQt.cmake. The motivation is that between releases of Qt and CMake, the features of Qt get out of sync with the features available through FindQt.cmake, but with config files

Re: [cmake-developers] Generating imported library targets without the cmake executable

2011-11-25 Thread Stephen Kelly
Stephen Kelly wrote: Hi there, I am working on installing CMake config files from the Qt repository so that there is less need for a FindQt.cmake. By the way, it would be very helpful if anyone tried to build and test this on windows and mac. The clone is at https://qt.gitorious.org

Re: [cmake-developers] Generating imported library targets without the cmake executable

2011-11-28 Thread Stephen Kelly
On 11/28/2011 05:51 PM, Brad King wrote: On 11/25/2011 10:02 AM, Stephen Kelly wrote: https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-qtbase/ the branch is cmake_files. The testing steps are: 1) build and install Qt It doesn't appear to build at all on Windows with VS 9

[cmake-developers] Windows build issues? (Was Re: Generating imported library targets without the cmake executable)

2011-11-28 Thread Stephen Kelly
Hi, Is Qt supposed to be buildable with VS 10 on Windows? Context here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2338/focus=2347 Thanks, Steve.---BeginMessage--- On 11/28/2011 11:57 AM, Stephen Kelly wrote: On 11/28/2011 05:51 PM, Brad King wrote: On 11/25/2011 10

Re: [cmake-developers] target_include_directories branch in stage

2011-11-29 Thread Stephen Kelly
Brad King brad.king@... writes: On 11/6/2011 5:45 PM, Stephen Kelly wrote:I'd prefer it to be though if we can sort out the issues with what should be the target feature set. Good. We can work on this and revise/rewrite the topic there first and then merge to next for testing when

Re: [cmake-developers] Generating imported library targets without the cmake executable

2011-11-29 Thread Stephen Kelly
Brad King wrote: On 11/29/2011 8:00 AM, Stephen Kelly wrote: Alexander Neundorf wrote: I can't generate the files. I'm asking people with windows and mac setups to generate them and post them for review. I don't have those setups. Just the ones for Linux would already help :-) I managed

Re: [cmake-developers] Generating imported library targets without the cmake executable

2011-11-29 Thread Stephen Kelly
Brad King wrote: On 11/29/2011 10:53 AM, Stephen Kelly wrote: Qt5Core_LIBRARY is intended to be the thing that users would use in the CMakeLists.txt. I've had another read of the Modules/readme.txt and I guess I need to change it to be consistent. So should I rename them or should I

Re: [cmake-developers] Generating imported library targets without the cmake executable

2011-11-29 Thread Stephen Kelly
Alexander Neundorf wrote: On Tuesday 29 November 2011, Stephen Kelly wrote: Alexander Neundorf wrote: I can't generate the files. I'm asking people with windows and mac setups to generate them and post them for review. I don't have those setups. Just the ones for Linux would already

Re: [cmake-developers] Generating imported library targets without the cmake executable

2011-11-29 Thread Stephen Kelly
Alexander Neundorf wrote: On Tuesday 29 November 2011, Brad King wrote: On 11/29/2011 10:53 AM, Stephen Kelly wrote: Qt5Core_LIBRARY is intended to be the thing that users would use in the CMakeLists.txt. I've had another read of the Modules/readme.txt and I guess I need to change

Re: [cmake-developers] Generating imported library targets without the cmake executable

2011-11-30 Thread Stephen Kelly
Brad King wrote: On 11/29/2011 8:40 PM, Stephen Kelly wrote: Alexander Neundorf wrote: Nevertheless, personally I would also provide the Qt5Core_LIBRARY variable, so if somebody wants to have a look what that variable currently actually is (would by the name if the imported target), he can

Re: [cmake-developers] cmake automoc breaks kde

2011-11-30 Thread Stephen Kelly
Alexander Neundorf wrote: Thanks. diff --git a/tier1/solid/solid/audiointerface.cpp b/tier1/solid/solid/audiointerface.cpp index ddf6cbc..98e42b2 100644 --- a/tier1/solid/solid/audiointerface.cpp +++ b/tier1/solid/solid/audiointerface.cpp @@ -67,4 +67,4 @@

Re: [cmake-developers] Generating imported library targets without the cmake executable

2011-11-30 Thread Stephen Kelly
Stephen Kelly wrote: Brad King wrote: On 11/30/2011 9:09 AM, Stephen Kelly wrote: Brad King wrote: Alex was proposing simply to provide the singular name as a variable but not to cache it. The only reason to cache a variable is when we're searching and need to let the user help out

Re: [cmake-developers] Generating imported library targets without the cmake executable

2011-11-30 Thread Stephen Kelly
Alexander Neundorf wrote: Static builds of Qt are no longer tested by Nokia at least as far as I know. I don't know if it is even possible to build Qt statically on all (or any) platforms anymore. Ah, ok. So if we (at work) would like to have static builds, we maybe should take action ?

Re: [cmake-developers] cmake automoc breaks kde

2011-12-01 Thread Stephen Kelly
Alexander Neundorf wrote: but this still means that even if we start to require cmake 2.8.7 for kdelibs4, we still need the standalone automoc (which I don't feel like maintaining). Well, kdelibs4 is not really going to get any more releases. I'm not sure it makes sense to change the

Re: [cmake-developers] target_include_directories branch in stage

2011-12-01 Thread Stephen Kelly
Brad King wrote: On 11/29/2011 7:34 AM, Stephen Kelly wrote: I've been working on this topic again, but I forgot that I had not merged it into next. I think I properly reverted it though. I added another commit to the revert-... branch to fully revert it. To avoid accidental merges of work

Re: [cmake-developers] target_include_directories branch in stage

2011-12-01 Thread Stephen Kelly
Brad King wrote: On 12/1/2011 3:47 PM, Stephen Kelly wrote: https://github.com/Kitware/CMake and use the Fork button Ok. I've pushed it to my gitorious repo for now. I'll remove the config stuff there and let you know when that's done. Should I push it to github too or is gitorious also

Re: [cmake-developers] cmake automoc breaks kde

2011-12-02 Thread Stephen Kelly
Alexander Neundorf wrote: You said that you can't detect this case, but why do you have to? Isn't there already a check for the Q_OBJECT macro in the cpp file? Wouldn't the logic be 'if the basename.moc file is included but there is no Q_OBJECT in the header, then moc the basename.h and put

Re: [cmake-developers] target_include_directories branch in stage

2011-12-02 Thread Stephen Kelly
Brad King wrote: On 11/29/2011 7:34 AM, Stephen Kelly wrote: I worked on the functionality for per-config target includes, but the syntax is not right yet. Please remove per-config support for now. Do you mean I should remove the UI feature of setting the INCLUDE_DIRECTORIES_DEBUG

Re: [cmake-developers] target_include_directories branch in stage

2011-12-04 Thread Stephen Kelly
David Cole wrote: I, for one, would really like to see per-target include directories in 2.8.7, even without per-config support to start with. Then, add the per-config support / new generator expressions in a later release. That seems unlikely to happen. If RC1 is Wednesday, it would have

Re: [cmake-developers] target_include_directories branch in stage

2011-12-04 Thread Stephen Kelly
Alexander Neundorf wrote: On Sunday 04 December 2011, Stephen Kelly wrote: David Cole wrote: I, for one, would really like to see per-target include directories in 2.8.7, even without per-config support to start with. Then, add the per-config support / new generator expressions in a later

Re: [cmake-developers] A few more changes to automoc before 2.8.7

2011-12-15 Thread Stephen Kelly
Alexander Neundorf wrote: And, again a question regarding wording, currently the warnings generated by automoc say Better do this and that for a more robust build. I'd like to have a better way to express it. Use this and that for STRICT mode compatibility. ? or for qmake compatibility ?

Re: [cmake-developers] A few more changes to automoc before 2.8.7

2011-12-16 Thread Stephen Kelly
Alexander Neundorf wrote: On Thursday 15 December 2011, Stephen Kelly wrote: Alexander Neundorf wrote: And, again a question regarding wording, currently the warnings generated by automoc say Better do this and that for a more robust build. I'd like to have a better way to express

Re: [cmake-developers] A few more changes to automoc before 2.8.7

2011-12-18 Thread Stephen Kelly
Alexander Neundorf wrote: On Friday 16 December 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Thursday 15 December 2011, Stephen Kelly wrote: Alexander Neundorf wrote: And, again a question regarding wording, currently the warnings generated by automoc say Better do

Re: [cmake-developers] A few more changes to automoc before 2.8.7

2011-12-18 Thread Stephen Kelly
Alexander Neundorf wrote: On Sunday 18 December 2011, Alexander Neundorf wrote: On Friday 16 December 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Thursday 15 December 2011, Stephen Kelly wrote: Alexander Neundorf wrote: And, again a question regarding wording, currently

Re: [cmake-developers] A few more changes to automoc before 2.8.7

2011-12-19 Thread Stephen Kelly
Alexander Neundorf wrote: On Sunday 18 December 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Sunday 18 December 2011, Alexander Neundorf wrote: On Friday 16 December 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Thursday 15 December 2011, Stephen Kelly wrote

Re: [cmake-developers] [CMake 0012645]: In GenerateExportHeader.cmake IS_ABSOLUTE is used with a variable name instead of a path

2012-01-03 Thread Stephen Kelly
Mantis Bug Tracker wrote: The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=12645 == Reported By:Michael Wild

[cmake-developers] Should a module attempt to find its own dependencies?

2012-01-08 Thread Stephen Kelly
Hi, I don't think I've ever seen a direct answer to this question. Is it something to be decided on a case by case basis? If so, then why is there no general case? I can see a possible reason that it is not solvable in the general case because sometimes the behaviour of find_package can be

Re: [cmake-developers] Should a module attempt to find its own dependencies?

2012-01-08 Thread Stephen Kelly
Alexander Neundorf wrote: On Sunday 08 January 2012, Stephen Kelly wrote: Hi, I don't think I've ever seen a direct answer to this question. AFAIK, yes, they should. FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib. Is it something to be decided on a case by case basis

Re: [cmake-developers] target_include_directories branch in stage

2012-01-09 Thread Stephen Kelly
David Cole wrote: How can this feature now be moved forward? Do I need to convince someone to volunteer to port the other generators? Should I just file a bug for porting the other generators and wait (possibly making the feature bitrot)? I volunteer to make sure this branch works with

Re: [cmake-developers] target_include_directories branch in stage

2012-01-23 Thread Stephen Kelly
David Cole wrote: On Fri, Jan 20, 2012 at 3:20 PM, Stephen Kelly steve...@gmail.com wrote: Hi, I've force pushed my branch: https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target- include-directories Brad King wrote: On 1/8/2012 11:47 AM, Stephen Kelly wrote: On 12/05

Re: [cmake-developers] target_include_directories branch in stage

2012-01-30 Thread Stephen Kelly
David Cole wrote: On Sun, Jan 29, 2012 at 11:44 AM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: OK... nearly complete now. Please review, then reply and tell me if you object to any of the 7 commits in this topic branch. No objections. They all seem fine. Great, thanks

[cmake-developers] Modifying RPATH feature to run tests uninstalled

2012-02-16 Thread Stephen Kelly
Hi there, One of the macros we have in KDE creates shell scripts to initialize environment variables needed on various platforms so that tests can be run before installation. If RPATH is enabled, the scripts are not needed, but RPATH is sometimes disabled, so the scripts are the solution to

[cmake-developers] Making GUI applications by default

2012-02-16 Thread Stephen Kelly
Hi there, Also in this thread one of the discussion topics was making CMake default to creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE or MACOSX_BUNDLE property on the executable target. http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=7005 By

Re: [cmake-developers] Making GUI applications by default

2012-02-17 Thread Stephen Kelly
Eric Noulard wrote: 2012/2/17 Stephen Kelly steve...@gmail.com: Hi there, Also in this thread one of the discussion topics was making CMake default to creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE or MACOSX_BUNDLE property on the executable target. http

Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled

2012-02-17 Thread Stephen Kelly
Marcel Loose wrote: Hi, On Fri, 2012-02-17 at 08:51 +0100, Alexander Neundorf wrote: -- 8 8 8 8 8 8 8 8 8 -- So the suggestion is a) Change CMAKE_SKIP_RPATH to only skip RPATH when installing, but not when building (I don't know if that's

Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled

2012-02-17 Thread Stephen Kelly
Marcel Loose wrote: Hi Stephen, On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote: -- 8 8 8 8 8 8 8 8 8 -- diff --git a/templates/tests/CMakeLists.txt b/templates/tests/CMakeLists.txt index d2e37d2..ad471c7 100644 --- a/templates/tests

Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled

2012-02-17 Thread Stephen Kelly
Eric Noulard wrote: 2012/2/17 Stephen Kelly steve...@gmail.com: Marcel Loose wrote: Hi Stephen, On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote: -- 8 8 8 8 8 8 8 8 8 -- diff --git a/templates/tests/CMakeLists.txt b/templates/tests

Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled

2012-02-17 Thread Stephen Kelly
Alexander Neundorf wrote: On Friday 17 February 2012, Stephen Kelly wrote: ... The other issue is regarding setting RPATH for the build step and not the install step, and what syntax should be used for that. The options are: a) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH

  1   2   3   4   5   6   7   8   9   10   >