Re: [cmake-developers] Adding CheckCXXSymbolsExists.cmake ?
On Wednesday 06 July 2011, Alexander Neundorf wrote: Hi, cmake has a CHECK_SYMBOL_EXISTS() macro for testing whether a symbol exists in a header /library. In KDE we have a slightly modified version of this, CHECK_CXX_SYMBOL_EXISTS(), which basically does the same, but using C++, so C++ headers can be checked. I'd like to add that to cmake. Any objections ? I just found that I started with this already 5 years ago: http://www.cmake.org/pipermail/cmake-developers/2006-September/000123.html Conclusion was that it's ok, but the existing check_something() macros should be renamed to check_something_C() and check_something_CXX() should be added. Not sure I like that, since it would deprecate all existing check_something() macros. So, just go ahead with adding it as CHECK_CXX_SYMBOL_EXISTS() or CHECK_SYMBOL_EXISTS_CXX() and if the macro name has no language in it, it is implicitely C ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Adding push/pop_required_vars() to cmake
Hi, in KDE we have two macros macro_push_required_vars() and macro_pop_required_vars(). They are intended to be used before setting one or more of the CMAKE_REQUIRED_INCLUDES/DEFINITIONS/etc. variables for a specific test, so that after the check the previous state can be easily restored. It works multilevel: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/cmake/modules/MacroPushRequiredVars.cmake Last time Brad suggested to rename them to push/pop_check_state(): http://www.cmake.org/pipermail/cmake-developers/2006-September/000137.html I don't have a strong opinion on the naming. push/pop_required_vars() or push/pop_check_state() ? Adding a cmake_ prefix ? And put them into CMakePushCheckState.cmake ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
Hi, in KDE we have a simple macro which helps with creating a FooConfigVersion.cmake for installation along the FooConfig.cmake file. Since that Version.cmake file in most cases looks basically the same, I thought it is a good idea to provide such a basic file, and the only thing which has to be changed there are the actual version numbers. This is this file: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/cmake/modules/BasicFindPackageVersion.cmake.in Additionally there is a small helper macro which takes the three version number components and does the configure_file(): https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/cmake/modules/MacroWriteBasicCMakeVersionFile.cmake so the user can then add the install(FILES ... ) command after that. IMO this is generic enough to be added to cmake. How ? As a combination of macro and cmake.in file as it is ? Or just the cmake.in file and let the users find out how to use that file themselves ? The problem with this is that the man page will not contain documentation about the cmake.in file, while it will contain documentation about the macro (if it is added as macro). Or only add the macro, and do file(WRITE ...) instead of configure_file() in it ? About the name: when added to cmake, I would probably simply strip the Macro prefix from it. Comments ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improved support for using cmake-based libraries in non-cmake projects
On Wednesday 06 July 2011, Alexander Neundorf wrote: On Monday 04 July 2011, Brad King wrote: On 07/03/2011 12:23 PM, Alexander Neundorf wrote: On Monday 20 June 2011, Brad King wrote: On 06/17/2011 05:09 PM, Alexander Neundorf wrote: I improved it somewhat, so IMO it is basically working now. There is now a branch UsingCMakeLikePkgConfig on stage. Would be nice if you could have a look. The patch series is hard to follow because it adds and removes some code/comments and adds a file too late. Please edit the topic with git rebase -i to clean it up and push again. There is now a new branch UsingCMakeLikePkgConfig2 in the stage. It should have somewhat nicer commits. Much easier, thanks. This is not yet ready to be merged, but it would be nice if it could get a review :-) In the first commit Make clLocalGenerator::GetTargetFlags() public please fix the typo s/cl/cm/. In the second commit Add find-package mode, which does nothing yet I think we should use an enumeration for the mode rather than separate ScriptMode and FindPackageMode booleans. It does not make sense to have both at once, so both flags can be replaced by a single enumeration value. I'll have a look. Done. There is now an enum which can have the values SCRIPT_MODE, FIND_PACKAGE_MODE and NORMAL_MODE. In the main commit, Implement find-package mode of cmake, there are some technical challenges remaining: (1) The code # this is ugly, and not enough for the multilib-stuff I guess if(UNIX AND EXISTS /usr/lib64) set(CMAKE_SIZEOF_VOID_P 8) endif() hints at this one. Some FindXXX modules or XXXConfig.cmake files may switch behavior off the target compiler and architecture. Without having a real enable_language() the files may not present accurate information. I don't think a full enable_language can be made to work in this mode, at least not efficiently. This problem may be a matter of passing more arguments into the mode to tell it things like the address size as necessary. Yes. I'll add something. Done. So, CMAKE_SIZEOF_VOID_P can be given to the script from the outside via -D. If this is not done, it checks for /usr/lib64. If found - 64bit. If it doesn't exist, it then does /usr/bin/file /usr/bin/file, and checks whether the output contains 64-bit. If so - 64bit. I think this should work for most cases. For the remaining cases CMAKE_SIZEOF_VOID_P has to be given from the outside (which is a configure script so this shouldn't be a problem). For the multiarch stuff: the script now uses the regexp as defined in Linux.cmake to check whether such a directory exists, and if so, uses the first one found. If there are multiple matching directories, this value again has to be given from the outside. I think both issues above should work for all one-architecture installations. (2) In the case that the to-be-found package really does provide a CMake package configuration file (FooConfig.cmake) then it may provide the libraries as imported targets. The Foo_LIBRARIES variable will contain only the logical names and not any real path information. You'll have to read one of the LOCATION_CONFIG properties from such imported targets to get an actual file path. This works already. I don't simply print the contents of the variable, but an executable target is added, and it links against the contents of the variable. Then cmake does all the rest and evaluates it, and generates a command line for the linker. Yes, already works :-) (3) This hunk: + // free generic one if generated +// this-SetGlobalGenerator(0); // setting 0-pointer is not possible +// delete gg; // this crashes inside the cmake instance will require further investigation and/or refactoring of existing code to address. Perhaps the changes can be included in the second patch or an additional patch in the series. I had a look. I could simply leave it as it is (and remove the comment), then the global generator which is created in this function will be deleted later on by the normal cmake dtor. Or I can change cmake::SetGlobalGenerator() so that it accepts a 0-pointer in findpackage mode, and deletes the old global generator (and call SetGlobalGenerator(0) then). I'd prefer the first solution, since it doesn't require code changes and there shouldn't be an actual problem. As I said, I think it's ok. (4) Tests should be added in another patch after this. They can wait until the rest has matured though so we know what to test ;) Yes :-) Yes. Another question: the cmake.m4 is based on the m4-file for pkgconfig, which has the GPL header at the top. So, the cmake.m4 still has that header at the top. Is this a problem ? I don't know how the license of a file, which is installed by cmake, but not compiled-in nor used by cmake itself influences cmake. I thought about asking e.g
[cmake-developers] Supporting imported targets in CHECK_CXX_SOURCE_COMPILES() and friends
Hi,
in KDE we have a copy of CHECK_CXX_SOURCE_COMPILES() which supports imported
targets in CMAKE_REQUIRED_LIBRARIES:
http://websvn.kde.org/branches/KDE/4.5/kdelibs/cmake/modules/CheckCXXSourceCompiles.cmake?revision=1143427view=markup
http://websvn.kde.org/branches/KDE/4.5/kdelibs/cmake/modules/HandleImportedTargetsInCMakeRequiredLibraries.cmake?view=markup
This means, you can put any ${FOO_LIBRARY} you got from some find-module into
CMAKE_REQUIRED_LIBRARIES and it will work, also if ${FOO_LIBRARY} is actually
an imported target and not a path to a library.
It works for us in KDE and I am not aware of problems with it. Also, the
number of imported targets is increasing, by more and more projects installing
Config.cmake files, so this is getting more important.
I can remember that quite some time ago I suggested to merge this into cmake,
but there were objections. I can't remember what the objections were, well,
actually I don't see a reason not to have that in cmake.
So, do these objections still exist or can I merge that into cmake ?
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Lots of unnecessary search PATHS in FindGIF.cmake and FindFreetype.cmake ?
On Wednesday 27 July 2011, Eric Wing wrote:
On 7/26/11, Alexander Neundorf neund...@kde.org wrote:
Hi,
I just had a look at FindGIF.cmake and FindFreetype.cmake.
Both have similar code:
...
What about the two PATH_SUFFIXES lib64 and lib ? They shouldn't be
necessary.
Or, how is lib64 handled if I just give /some/dir/lib as argument to
PATHS ?
Is a lib64 version then checked too ? (I think no, but I'm not sure).
Most of those probably can be removed safely. Those modules were
written in another era when CMake had very little in the common core
and no Mac OS X Framework support.
That HKEY OSG_ROOT shouldn't be there. I don't know how that got snuck
in. I was advocating for generic things like $ENV{GIF_DIR}. But now
that it is there...I'm not sure about removing it.
/usr/freeware was added because I think I got complaints from IRIX and
Gentoo users?
I forgot which platforms used /usr/local/X11. (Does/did FreeBSD use this
one?)
Can you please give the FindGIFAndFreetypeCleanupAndEnhancements branch a try
?
http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/FindGIFAndFreetypeCleanupAndEnhancements
I removed the dirs which are IMO unnecessary.
What about ~/Library/Frameworks ?
Is this searched by default on OSX or not ?
If it works for you, I'll merge it into next then.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On Thursday 07 July 2011, Alexander Neundorf wrote:
On Thursday 07 July 2011, Brad King wrote:
On 7/6/2011 4:00 PM, Alexander Neundorf wrote:
Since that Version.cmake file in most cases looks basically the same
They're only the same within a specific community's versioning scheme.
The whole reason find_package loads package-provided version check
files is to avoid imposing a versioning/compatibility scheme. If
we provide a template then we should name it after the scheme it
follows.
Provide a module with macros to generate version files with different
common schemes. Use configure_file with CMakeConfigurableFile.in as
the input if you don't want a custom .in file.
I'd do that, but when I first wrote that file, I was actually surprised
that I could think of only one way to do it:
if (currentVersion requestedVersion)
{
compatible = false;
}
else
{
compatible = true;
if (currentVersion == requestedVersion)
{
exact = true;
}
}
I think everything else are special cases, at least I can't think of other
generic cases.
How could another common scheme look like ?
Any ideas ?
Beside that, attached is a modified version which now also fails if
SIZEOF_VOID_P of the installed version differs from the current on.
Alex
# This is a very basic file for the new style find_package() search mode,
# i.e. Config-mode.
# In this mode find_package() searches for a packageConfig.cmake
# file and an associated packageVersion.cmake file, which it loads to check
# the version number.
# This file can be used with configure_file() to generate such a file for a
project
# with very basic logic.
# It sets PACKAGE_VERSION_EXACT if the current version string and the requested
# version string are exactly the same and it sets PACKAGE_VERSION_COMPATIBLE
# if the current version is = requested version.
# If this is not good enough for your project, you need to write your own
# improved packageVersion.cmake file.
set(PACKAGE_VERSION @BAR_VERSION_MAJOR@.@BAR_VERSION_MINOR@.@BAR_VERSION_PATCH@)
if(NOT @CMAKE_SIZEOF_VOID_P@ STREQUAL ${CMAKE_SIZEOF_VOID_P})
math(EXPR installedBits @CMAKE_SIZEOF_VOID_P@ * 8)
set(PACKAGE_VERSION ${PACKAGE_VERSION} (${installedBits}bit))
set(PACKAGE_VERSION_COMPATIBLE FALSE)
# return()
#endif()
else()
if(${PACKAGE_VERSION} VERSION_LESS ${PACKAGE_FIND_VERSION} )
set(PACKAGE_VERSION_COMPATIBLE FALSE)
else(${PACKAGE_VERSION} VERSION_LESS ${PACKAGE_FIND_VERSION} )
set(PACKAGE_VERSION_COMPATIBLE TRUE)
if( ${PACKAGE_FIND_VERSION} STREQUAL ${PACKAGE_VERSION})
set(PACKAGE_VERSION_EXACT TRUE)
endif( ${PACKAGE_FIND_VERSION} STREQUAL ${PACKAGE_VERSION})
endif(${PACKAGE_VERSION} VERSION_LESS ${PACKAGE_FIND_VERSION} )
endif()___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improved support for using cmake-based libraries in non-cmake projects
On Friday 29 July 2011, Brad King wrote: On 07/18/2011 03:43 PM, Alexander Neundorf wrote: ... Another question: the cmake.m4 is based on the m4-file for pkgconfig, which has the GPL header at the top. So, the cmake.m4 still has that header at the top. Is this a problem ? Yes. We at least need to distribute the GPL COPYING file with it. In the source tree the two files would need to appear together in a directory separate from any other files. I don't know how the license of a file, which is installed by cmake, but not compiled-in nor used by cmake itself influences cmake. CMake doesn't even invoke the code in that file so the license does not propagate. However I'm hesitant to distribute anything with CMake that is not compatible with our main license. It will be a PITA to document the licensing situation properly. Ok. I'll try to find somebody who speaks autoconf/m4 to help me with this and write a BSD-licensed file from scratch. Or do you know somebody who is good at this ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On Monday 01 August 2011, Alexander Neundorf wrote: On Monday 01 August 2011, Brad King wrote: On 07/31/2011 04:09 PM, Alexander Neundorf wrote: I'm not sure which syntax I like better. The one with the macro feels more high-level, but maybe hides too much what is actually going on (which is not much). The one where the user must use configure_file() directly feels more low-level, but doesn't try to make a secret of what's going on, which may be better to encourage users to write their own version files. Which one would you prefer ? I'll add tests for the one we decide to use. I like the macro better. It will allow us to extend the capabilities later while retaining compatibility. If we let people configure the file directly then if we add more fields that need replacement in the future then old versions may stop working because there are no defaults for new fields. I pushed and merged now a 3rd branch WriteConfigVersionFile_2TemplateFiles which does both: it provides the Are you ok with this branch or are there issues left (...since it wasn't merged into master on Tuesday) ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting environment variables for builds
On Monday 08 August 2011, Brad King wrote: On 8/8/2011 4:24 AM, Johan Björk wrote: This has been discussed a billion times, so I'll keep it short. Problem: Some parts of the build requires a environment variable to be set Solution: Several workarounds, use custom commands, wrapper scripts etc. While the solution works fine for basic stuff, I have several toolchains etc that requires environment variables to be installed for them to work. CMake has always assumed that the environment is setup correctly for the desired toolchain before either cmake or make runs. Typically developers have dealt with this by naming the build tree after the toolchain needed as a reminder of the environment needed. I'm sure an alternative would be welcomed by many. Since I'm using cmake --build for all my building, I am thinking about creating a new command in cmake that will store certain environment variables in the cache, and if building using cmake --build, they will be set before the build starts. This sounds like a great compromise. I don't think the cache is the right place to put this though. I think you can create your own file like CMakeFiles/cmake--build.env and give it a format customized for this purpose (like one line per variable or something). In the Eclipse project generator, I do something similar. Depending on the used compiler, a set of env.variables are stored in the cache and written into the project file, so they will be set when Eclipse invokes make. E.g. for the Intel compiler that's the license-related one, for MSVC it's LIBDIR or something like this. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Test for compiler flags ineffective with xlc?
Hi Stephen :-)
On Thursday 11 August 2011, Stephen Kelly wrote:
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 I just exclude that platform from
performing the test? How?
Would if (${CMAKE_CXX_COMPILER_ID} MATCHES xlC) match?
Should be XL, see Modules/CMakeCCompilerId.c.in, there they are all defined.
You can also see this here in the output from the cmake run:
http://www.cdash.org/CDash/viewConfigure.php?buildid=1419259
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Tuesday 16 August 2011, Alexander Neundorf wrote: ... There is now a branch AutomocForQt on the cmake stage. Docs and a test are still missing. It has a test now. Docs are still missing. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Tuesday 16 August 2011, Alexander Neundorf wrote: On Tuesday 16 August 2011, Alexander Neundorf wrote: ... There is now a branch AutomocForQt on the cmake stage. Docs and a test are still missing. It has a test now. Docs are still missing. Now it also has docs. I haven't merged it to next yet. Any objections ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Tuesday 16 August 2011, David Cole wrote: 2011/8/16 Alexander Neundorf neund...@kde.org: On Tuesday 16 August 2011, Alexander Neundorf wrote: On Tuesday 16 August 2011, Alexander Neundorf wrote: ... There is now a branch AutomocForQt on the cmake stage. Docs and a test are still missing. It has a test now. Docs are still missing. Now it also has docs. I haven't merged it to next yet. Any objections ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Brad and I just read through some of your recent commits. In the Tests/CMakeLists.txt there's logic that looks like this: IF(NOT QT4_FOUND) FIND_PACKAGE(Qt4) IF(QT4_FOUND) ... ENDIF() ENDIF() Could you change it to this? IF(NOT QT4_FOUND) FIND_PACKAGE(Qt4) ENDIF() IF(QT4_FOUND) ... ENDIF() That way, when we have builds of CMake where Qt is on (to build cmake-gui) it will run the test. As it stands now, looks like it will not run the test when we already *know* we have Qt available... Hmm, yes. Not sure what I thought when writing this. After that, go ahead and merge to 'next' and see how it looks on the dashboard. Done. Can a merge to next actually also be undone ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote: 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_INCLUDE_CURRENT_DIR ON) instead of this: set(CMAKE_AUTOMOC ON) Don't know. I'm usually ok with having to set the include directories explicitely. What do others think ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Sunday, September 18, 2011 07:11:58 PM Marcus D. Hanwell wrote: On Sun, Sep 18, 2011 at 6:39 AM, Alexander Neundorf neund...@kde.org wrote: On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote: 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_INCLUDE_CURRENT_DIR ON) instead of this: set(CMAKE_AUTOMOC ON) Don't know. I'm usually ok with having to set the include directories explicitely. What do others think ? It seems to me that if you always need to do both for it to work, then it should be a candidate for consolidation. set(CMAKE_INCLUDE_CURRENT_DIR ON) automatically adds the current source dir and the current binary dir for each directory which has a target as include directory. This is a bit more than necessary for automoc. For automoc for every target which needs moc'ing its current binary dir has to be added. So, I'm still not sure. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] UsePkgConfig: improve documentation
On Thursday, September 22, 2011 03:00:33 PM Rolf Eike Beer wrote: On Thursday, September 22, 2011 01:52:51 PM Rolf Eike Beer wrote: From 3f500a5c655cc4c12ecf6f774602b2a10cae0365 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer e...@sf-mail.de Date: Thu, 22 Sep 2011 13:48:15 +0200 Tell the people in the documentation which module to use instead. Thanks, merged into next (the MinorPkgConfigDocImprovement branch) Well, wrong. You took the patch and committed the changes, so once again Nitpicking: what I committed were actually not exactly your changes, but fixes inspired by your patch ;-) Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] UsePkgConfig: improve documentation
On Tuesday 27 September 2011, Rolf Eike Beer wrote: On Thursday, September 22, 2011 03:00:33 PM Rolf Eike Beer wrote: On Thursday, September 22, 2011 01:52:51 PM Rolf Eike Beer wrote: From 3f500a5c655cc4c12ecf6f774602b2a10cae0365 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer e...@sf-mail.de Date: Thu, 22 Sep 2011 13:48:15 +0200 Tell the people in the documentation which module to use instead. Thanks, merged into next (the MinorPkgConfigDocImprovement branch) Well, wrong. You took the patch and committed the changes, so once again Nitpicking: what I committed were actually not exactly your changes, but fixes inspired by your patch ;-) Indeed, I did not have the extra typo in it. Another chance for me to send a patch ;) Ok, committed. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse for 2.8.6 ?
Hi, I just merged the branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse into next, it fixes http://public.kitware.com/Bug/view.php?id=12392 . It's a small patch, and helps people using Eclipse + cmake + ccache. Can this still make it into 2.8.6 please ? Thanks Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse for 2.8.6 ?
On Saturday 01 October 2011, David Cole wrote: Brad and Bill and I will look at this Monday. We are closing in on the final 2.8.6 release. If we take changes Monday, we'll merge them, await the dashboard results on Tuesday morning, and then build the final 2.8.6. If we take no changes, I'll build 2.8.6 on Monday. You must admit, this fix affects an awfully small percentage of the total CMake user base... So we may not take it. But, since it's so small, we may. That's what I thought too :-) Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting the link interface and dependencies in one command
On Sunday 02 October 2011, Rolf Eike Beer wrote: On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf neund...@kde.org wrote: If library bar internally uses symbols from foo, it needs to link against foo. Correct. But if bar doesn't expose symbols from foo in its interface, and my executable hello links against bar, it doesn't also have to be linked against foo. This saves startup time and other things. Packagers also like that. No, you got something wrong here. Let me restate my sentence from above more verbose: ... and my executable hello links against bar, using only symbols exposed by bar, and not using symbols from foo, it doesn't also have to be linked against foo. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 0/7] Preparation for Ninja generator: refactorings, bug fixes
On Tuesday 04 October 2011, Peter Kümmel wrote: On 03.10.2011 15:03, Brad King wrote: On 10/2/2011 1:41 PM, Peter Collingbourne wrote: I have modified the commit message to include more details, and pushed a modified branch to github. I've fetched the latest version of the branch. Thanks for the updates. -Brad Could you also enable Ninja files for CodeBlock's generators? And please also for Eclipse :-) (it's done the same way as for CodeBlocks) Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integrate API/ABI checker to the CMake
On Friday 07 October 2011, Andrey Ponomarenko wrote: Hello, I have an idea to improve the CMake build system by integrating with the abi-compliance-checker [1] tool. It's a tool for checking for API/ABI backward compatibility of C/C++ libraries. In the Java world there is an alternative tool called Clirr, which is already integrated to the Ant and Maven build systems as a plug-in. But there is no such thing in the C/C++ world yet. So, people have to create custom scripts (phonon/cmake [2], mysql++/make [3], ...) to integrate the abi-compliance-checker tool into the build system. It would be great if CMake users could be able to check API/ABI changes using two easy built-in CMake commands: make abidump and make abicheck, without the need to understand how the abi-compliance-checker tool works. The first command (make abidump) should create a snapshot of a stable library ABI, which will be compared with the next releases by the second command (make abicheck): make abidump: abi-compliance-checker --lib=name --dump=v1.xml --dump-path=snapshot-v1.abi.tar.gz make abicheck: abi-compliance-checker --lib=name --d1=snapshot-v1.abi.tar.gz --d2=v2.xml v1.xml and v2.xml are XML-descriptors of old (snapshot) and new (current) versions of a library(ies): version 1.0 /version headers /directory/with/headers/ /headers libs /directory/with/libraries/ /libs I'm not familiar with the CMake internals and cannot implement this feature by myself. It would be great if some experts in CMake could write it. Considering the great number of C/C++ libraries using CMake, this feature should make upstream development of C/C++ libraries more stable. Maybe you don't have to be familiar with CMake internals to do this. It may be that this can be done simply in cmake script, but putting some macros or functions into a CMakeABICheck.cmake file or something like this. Did you try to use add_custom_target() to exeucte the described steps ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Question/problem with cmSourceGroup
Hi, I'm currently trying to add support for the source_group() command to the Eclipse project generator. It's not as straighforward as I expected. I expected that if I do source_group(Foo FILES main.cpp) in the CMakeLists.txt, that then in the generate step, there would be a cmSourceGroup object with that name (Foo), this is indeed the case, and that I then could simply iterate over the files of this source group, which would give me main.cpp. This is not the case. The source_group() command puts main.cpp into the member std::setcmStdString GroupFiles of cmSourceGroup, and cmSourceGroup::GetSourceFiles() returns the member std::vectorconst cmSourceFile* SourceFiles; which is empty in my case. So, how should source groups be handled in the Eclipse generator ? There are already links to the source dir and to each project-dir, so the groups would only provide additional, well, grouping. But cmSourceGroup::GroupFiles is private and I don't see a way to access it, the only place I found where its contents are read is in cmSourceGroup::MatchesFiles(), but there its contents are compared with a function argument, so it still doesn't give me read-access to the set of added files. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Nitpicking ProcessorCount.cmake
Hi, I just used ProcessorCount.cmake the first time. I noticed a small issue: AFAIK module file names in cmake use CamelCase, while the macros/functions use underscores: SomeCoolStuff.cmake - some_cool_stuff() ProcessorCount.cmake doesn't do this, the function is named processorcount() IMO we should keep it this way, since it is defacto-standard, and it also makes sense, since I always recommend to use all-lower-caps style for commands, or at least all-upper-caps. And when using all-lower, the function name is not that easy to read anymore. So, should I rename it to processor_count() and add a processorcount() for backward compatibility ? Alex P.S. it is similar with ExternalPackage.cmake, externalproject_add() doesn't use the old style, it would have been external_project_add() instead. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Merging cmake-link-interface-libraries into master?
On Tuesday 25 October 2011, Stephen Kelly wrote: ... I think I read somewhere that next gets re-branched from master periodically. How often does that happen? Usually every Tuesday. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Monday 31 October 2011, David Faure wrote:
Hi Alex,
The latest changes in cmake-git (probably the merge of
AutomocFindQ_OBJECTAlwaysInHeader) break the compilation of kde-frameworks.
This is for fixing http://public.kitware.com/Bug/view.php?id=12533
Before:
Generating kauthactionwatcher.moc
AUTOMOC: Checking kauthactionwatcher.cpp
moc [...] -o kauthactionwatcher.moc kauthactionwatcher.h
After:
AUTOMOC: Checking kauthactionwatcher.h
AUTOMOC: Checking kauthactionwatcher.cpp
Generating moc_kauthactionwatcher.cpp
moc [...] moc_kauthactionwatcher.cpp kauthactionwatcher.h
leading to
Error: moc_kauthactionwatcher.cpp:75:22: error: invalid use of incomplete
type 'struct KAuth::ActionWatcher::Private'
Generating kauthactionwatcher.moc
moc [...] -o kauthactionwatcher.moc kauthactionwatcher.cpp
kauthactionwatcher.cpp:0: Note: No relevant classes found. No output
generated.
This is a typical (kde) case where the .cpp incudes the .moc, for the
object defined in the .h.
Shouldn't it include moc_kauthactionwatcher.cpp ?
Is this really a typical case, i.e. is that done in many places ?
I thought the rule is that if there is a include foo.moc, the Q_OBJECT is in
the same cpp file.
That's also what is documented for cmake 2.8.6.
If it did additionally other things, this was more or less accidentially.
Apparently it now creates two moc files, one for the .cpp file (empty) and
Yes, because kauthactionwatcher.moc is included.
one for the .h file (but with the wrong name, so not included during
compilation).
Yes, because it contains a Q_OBJECT macro.
The logic which is currently implemented is:
1. if foo.cpp includes foo.moc, run moc on foo.cpp and generate foo.moc
2. run moc on all header files bar.h which contain Q_OBJECT and generate
moc_bar.cpp from them
(which in detail means:
2.1 for every included moc_xyz.cpp (no matter in which file), search for a
corresponsing xyz.h/hxx/hpp file and run moc on it
2.2 for every bar.cpp file, check whether there is a corresponding
bar.h/hpp/hxx file and collect it
2.3 check for a Q_OBJECT macro in all collected header files and all header
files listed explicitely as a source for the target, and run moc on them. If
the resulting moc_xyz.cpp file has not been included in any source file,
include it in targetname_automoc.cpp, which is built as part of the target )
Step 2.2 already involves guessing, which I don't like.
Beside that, IMO these are clear rules, which are easy to understand.
With the old behaviour it was actually ambigous:
foo.h:
class Foo
{
Q_OBJECT
};
foo.cpp:
Foo::Foo() {}
#include foo.moc
#include moc_foo.cpp
This would have generated twice the same moc file, I think. IMO this is really
confusing.
Now it is simple: foo.moc from foo.cpp, moc_foo.cpp from foo.h.
If this is really done in many places in KDE, I'll add some workaround, but I
think the default behaviour should stay as it is now in cmake git.
How does qmake handle such cases ?
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] To warn or to error out ? - wording and compatiblity
Hi, when using out-of-source builds and the Eclipse CDT project generator, a linked resource is created in the Eclipse project file, which points to CMAKE_SOURCE_DIR, so the user can browse the source directory. Now, when CMAKE_BINARY_DIR is a subdirectory of CMAKE_SOURCE_DIR (e.g. MyProject/build/ ), such a linked resource can't be created, and the resulting project file still works, but is less usable. I just added a warning, so that cmake now says: -- Configuring done CMake Warning in CMakeLists.txt: The build directory is a subdirectory of the source directory. This is not supported well by Eclipse. It is strongly recommended to use a build directory which is not a subdirectory of the source directory. -- Generating done I'm thinking about using FATAL_ERROR instead of warning for this, since the resulting project file without that link really feels wrong, and I recommend everybody to not build in a subdir of the source dir. This would have the effect that a build dir which was working until now does not work anymore with the next cmake release, the user would have to create a new build dir in some other location. Would this be acceptable ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Nitpicking ProcessorCount.cmake
On Sunday 23 October 2011, Alexander Neundorf wrote: Hi, I just used ProcessorCount.cmake the first time. I noticed a small issue: AFAIK module file names in cmake use CamelCase, while the macros/functions use underscores: SomeCoolStuff.cmake - some_cool_stuff() ProcessorCount.cmake doesn't do this, the function is named processorcount() IMO we should keep it this way, since it is defacto-standard, and it also makes sense, since I always recommend to use all-lower-caps style for commands, or at least all-upper-caps. And when using all-lower, the function name is not that easy to read anymore. So, should I rename it to processor_count() and add a processorcount() for backward compatibility ? Alex P.S. it is similar with ExternalPackage.cmake, externalproject_add() doesn't use the old style, it would have been external_project_add() instead. -- Any opinions ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] To warn or to error out ? - wording and compatiblity
On Tuesday 01 November 2011, Eric Noulard wrote: 2011/11/1 Alexander Neundorf neund...@kde.org: ... and I'd be very happy if this could be solved. Me too. I'll dig a little bit on the Eclipse side again, but generating 2 files in the source does not look like a big deal. The thing is that it would not be possible to create multiple build trees with Eclipse project files for one source tree (because the .project/.cproject files from one build tree would overwrite the .project/.cproject files from the other build trees). Do you know whether adding the source dirs as SOURCE pathentries maybe makes the version control stuff appear ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Alternative Config.cmake format (was: Installing Qt5Config.cmake from the Qt repo?)
On Tuesday 01 November 2011, Brad King wrote: On 10/31/2011 5:20 PM, Alexander Neundorf wrote: Not sure what the other cmake developers would think about supporting an additional file format for the Config.cmake files, e.g. xml or json, so they could be easily used and generated also by other tools. I.e. not only by/for cmake, but basically a standard format for installed libraries to provide information about themselves. Something like: libs lib nameQtCore/name configsdebug;release/configs location config=debug/usr/lib/libQtCore.so/location include/usr/include/QtCore/include ... /lib /libs I've thought about that a few times. This kind of format is hard to define generally without lots of use cases. I suggest that you design a prototype for such a format that is sufficient for Qt's needs. Write a Qt5Config.cmake that comes with Qt5 and *parses* the Qt5Config.xml file itself and sets the proper variables as CMake code expects. Then you can tweak and refine it without being delayed by CMake's release schedule since the parser comes with the format. After it has matured and perhaps a few other projects have picked it up we can consider adding first-class support for it in CMake. Hmm, ok. Would you prefer XML, JSON or something else ? When you write Qt5Config.cmake that comes with Qt5 and *parses* the Qt5Config.xml file itself do you mean to file(READ ...) then xml file in the Config.cmake file and then do a lot of regexp matching on the xml, or do you have a better idea ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Alternative Config.cmake format
On Tuesday 01 November 2011, Brad King wrote: On 11/1/2011 1:20 PM, Alexander Neundorf wrote: Would you prefer XML, JSON or something else ? I have no preference. If the format is simple enough to parse in CMake code then it can't be too hard to parse with a C++ implementation later ;) However, note that you're trying to set a precedent for a cross-platform replacement of pkg-config .pc files. That may have implications on the format choice. Yes, I'm aware of that. When you write Qt5Config.cmake that comes with Qt5 and *parses* the Qt5Config.xml file itself do you mean to file(READ ...) then xml file in the Config.cmake file and then do a lot of regexp matching on the xml, or do you have a better idea ? Yes, I meant that the Qt5Config.cmake file should do the parsing. You can use file(STRINGS) to load the input file as a list of lines suitable for use with foreach()'s IN LISTS mode. Ok. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Development] Installing Qt5Config.cmake from the Qt repo?
On Tuesday 01 November 2011, craig.sc...@csiro.au wrote: ... If you do that, you create a circular dependency, since CMake requires Qt to build its GUI application. Yes, you could build CMake's command line tools only, then Qt, then build CMake's GUI app, or alternatively you could install some previously built CMake package before building Qt, but these are steps that should not be necessary. I don't think that's a problem. CMake has the same issue itself, you need cmake to build cmake. So, what you do is you can either bootstrap cmake (then first a stripped down version of cmake is built, which then builds the full cmake), or use an older version of cmake to build the new cmake. The same could be done here. Use cmake and cmake-gui built against Qt x.y to build Qt x.y+1. If there is no Qt at all, cmake-gui will not be built, it is optional. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] cmake::GetCMakeCommand() wrong in ccmake
Hi, in ccmake, cmake::GetCMakeCommand() returns a wrong path when ccmake was invoked from the PATH. CMakeCommand is in ccmake computed this way (in cmCursesMainForm.cxx): std::string whereCMake=cmSystemTools::GetProgramPath(this-Args[0].c_str()); whereCMake += /cmake; ... this-CMakeInstance-SetCMakeCommand(whereCMake.c_str()); Now if this-Args[0] is simply ccmake, then whereCMake becomes /cmake, which is wrong. What would be the right way to fix this ? Check whether whereCMake is empty, and only add the / if it is not empty ? Set it to GetDefinition(CMAKE_COMMAND), which is set if I see correctly in cmake::AddCMakePaths(), which seems to always set the full path ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Wednesday 02 November 2011, Stephen Kelly wrote: 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 seen this in several places in Qt code. Grepping I found one in qt48/src/scripttools/debugging/qscriptenginedebugger.cpp QT_END_NAMESPACE #include qscriptenginedebugger.moc #include moc_qscriptenginedebugger.cpp I had a look now too. Why do they include both files here ? Using qmake, the qscriptenginedebugger.moc is as far as I can see, for the moc from the cpp file, while moc_qscriptenginedebugger.cpp is for the moc from the header. Now, why is the moc_...cpp actually #included at all ? Isn't it enough to list the header in the qmake file, and it will be moced ? Also, in qmake/options.cpp I see the follow code: Option::cpp_moc_mod = ; Option::h_moc_mod = moc_; ... Option::cpp_moc_ext = .moc; Option::h_moc_ext = .cpp; which seems to say that the moc file for foo.cpp will be foo.moc, while the moc file for foo.h will be moc_foo.cpp (so it can be built as a standalone cpp file). Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Sunday 06 November 2011, Thiago Macieira wrote: On Sunday, 6 de November de 2011 18:42:42 Alexander Neundorf wrote: On Wednesday 02 November 2011, Stephen Kelly wrote: 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 seen this in several places in Qt code. Grepping I found one in qt48/src/scripttools/debugging/qscriptenginedebugger.cpp QT_END_NAMESPACE #include qscriptenginedebugger.moc #include moc_qscriptenginedebugger.cpp I had a look now too. Why do they include both files here ? Using qmake, the qscriptenginedebugger.moc is as far as I can see, for the moc from the cpp file, while moc_qscriptenginedebugger.cpp is for the moc from the header. Now, why is the moc_...cpp actually #included at all ? Why not? Isn't it enough to list the header in the qmake file, and it will be moced ? That is correct. That's what creates the moc_cpp file. If the file is #included by anything, it isn't added to the list of sources to be compiled. So compiling is a bit faster. Any other reasons/advantages ? Am I right that with qmake foo.moc is always generated from the cpp file, while moc_foo.cpp is always generated from the header file ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories branch in stage
On Sunday 06 November 2011, Stephen Kelly wrote:
Stephen Kelly wrote:
Issues:
* I have only tried to implement this with the makefile generator and
have so far only tested it with Unix Makefiles. One of the bugs says
XCode can't do source-level includes. Can it do target-level includes?
Would I have to implement this for all generators before it would be
considered for acceptance?
* There's scope for refactoring the new code in my branch as well as
potentially refactoring with the cmIncludeDirectoriesCommand.
* There's scope for optimization.
* I haven't written any tests yet.
Related to Alex's remarks, there may also be scope for PUBLIC_INCLUDES and
PRIVATE_INCLUDES keywords.
I think the normal include directories should be treated as PRIVATE, while
the PUBLIC ones should have to be set explicitely.
Assuming a library would have those PUBLIC_INCLUDES set, should they be used
automatically when linking against this library using target_link_libraries(),
so that the following two lines add the PUBLIC_INCLUDES from the myLib library
to the compilation of foo ?
add_executable(foo ${srcs} )
target_link_libraries(foo myLib)
I'd say no, because it would be invisible in this code that the
target_link_libraries() call adds an include-directory to the compilation.
This will make for harder debugging/understanding CMakeLists.txt you didn't
write yourself.
The target_include_directories() command from the other email could help with
this:
add_executable(foo ${srcs} )
target_link_libraries(foo myLib)
target_include_directories(foo /some/include/dir myLib)
or maybe an extra keyword for target_link_libraries(), something like ?
add_executable(foo ${srcs} )
target_link_libraries(foo myLib USE_INCLUDE_DIRECTORIES)
Just some ideas...
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories branch in stage
On Monday 07 November 2011, Alexander Neundorf wrote: On Sunday 06 November 2011, Stephen Kelly wrote: 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/foc us =39114 I've pushed the target-include-directories branch to stage, which implements the feature. I started out as prototyping, but I ended up implementing API that I think makes sense. I have not merged it into next yet as it is not certain if it should be in the next release. I'd prefer it to be though if we can sort out the issues with what should be the target feature set. David mentioned one issue is whether the include directories of a target property should overwrite those of the directory property (added with the command include_directories). Like others on the other thread, I would expect the final list of includes to be determined by addition. I replied over there to this question. Here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39114 Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 0/7] Preparation for Ninja generator: refactorings, bug fixes
On Wednesday 09 November 2011, Peter Collingbourne wrote: On Tue, Oct 04, 2011 at 11:21:00PM +0200, Peter Kümmel wrote: On 04.10.2011 23:19, Peter Kümmel wrote: On 03.10.2011 15:03, Brad King wrote: On 10/2/2011 1:41 PM, Peter Collingbourne wrote: I have modified the commit message to include more details, and pushed a modified branch to github. I've fetched the latest version of the branch. Thanks for the updates. -Brad Could you also enable Ninja files for CodeBlock's generators? This doesn't appear to work here. I ran CMake with the CodeBlocks/Ninja generator over the CMake project, and received the following error in CodeBlocks when I tried to build: Using makefile: Makefile make: Makefile: No such file or directory make: *** No rule to make target `Makefile'. Stop. Process terminated with status 2 (0 minutes, 0 seconds) 0 errors, 0 warnings This is with CodeBlocks version 10.05. The fix may be trivial, but I don't know how easy it would be to teach CodeBlocks to use an alternative build tool. And maybe it is also trivial for 'Eclipse CDT4'. It isn't. I ran CMake with the Eclipse/Ninja generator over the CMake project, and I received a segmentation fault. It seems that the Eclipse generator assumes that the underlying generator is the Unix Makefile generator (see the static_cast on line 1038 of cmExtraEclipseCDT4Generator.cxx). Yes, there may be some dependencies, but there shouldn't be anything serious. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files safer
On Saturday 12 November 2011, Alexander Neundorf wrote: Hi, I added a branch CheckImportedFileExistenceInConfigDotCMakeFiles cmake stage. This is the commit: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=1b12babe0cef55a0d5531a9d0d453a15598eb467 Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files safer
On Monday 14 November 2011, Brad King wrote: On 11/12/2011 3:53 PM, David Cole wrote: And, in my opinion, if there are multiple possible causes of the problem then we should enumerate them in a message to the user, just as you've done here in this email back to me. And we should try to put them in the order of likelihood, so when they read it top-down, they read the smallest amount possible before having the a-ha moment where they realize what went wrong earlier. Yes. The wording needs to make it clear that this is *not* a problem with CMake or the files it generated or is loading. It is a problem with the path between CMake generating the files and them appearing on the user's disk. Instead of adding the code to the bottom of GenerateImportPropertyCode please create a separate method next to it for that part. Done, in an updated version of the CheckImportedFileExistenceInConfigDotCMakeFiles branch. If there are no more objections, I'll merge tomorrow into next. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files safer
On Monday 14 November 2011, you wrote: On 11/14/2011 4:01 PM, Alexander Neundorf wrote: Instead of adding the code to the bottom of GenerateImportPropertyCode please create a separate method next to it for that part. Done, in an updated version of the CheckImportedFileExistenceInConfigDotCMakeFiles branch. Looks good. My remaining hesitation is that the message gets duplicated many times in the targets file and takes a lot of (visual) space but its presence does not add much information for a (human) reader. I wonder if we can accumulate a list of files to be checked and add one test at the end of the targets file that looks for everything and fails with a single message. I could do function(check_for_file _file _target) if(NOT EXISTS _file) message(FATAL_ERROR ... long error message...) endfunction() check_for_file(libFoo123.so Foo) ... check_for_file(libBar123.so Bar) Or I could collect the files and targets together, but then the error message becomes less straigh forward. Right now it is: The file libbar.so.1.2.3 for the imported target bar does not exist. There are multiple possible reasons: * the file libbar.so.1.2.3 has been manually deleted, renamed or moved to another location * a previous install or uninstall procedure did not run successfully to its end * the installation package was faulty, and contained BarTargets.cmake, but not libbar.so.1.2.3, which must always be installed together. Then it could be: There were files missing for imported targets. There are multiple possible reasons: * the files have been manually deleted, renamed or moved to another location * a previous install or uninstall procedure did not run successfully to its end * the installation package was faulty, and contained BarTargets.cmake, but not the corresponding files, although they must always be installed together. Missing files: libbar123.so (for target bar) I'm not sure in the second version is as clear to understand as the first one, since it has to talk generally about the files in the text, while the first one can directly use libbar.so.123. Also, since this should be a rare error case, I'm not sure it makes sense to optimize it for the case of multiple missing files. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files safer
On Tuesday 15 November 2011, Brad King wrote:
On 11/15/2011 1:24 PM, David Cole wrote:
On Tue, Nov 15, 2011 at 1:19 PM, Alexander Neundorfneund...@kde.org
wrote:
function(check_for_file _file _target)
if(NOT EXISTS _file)
message(FATAL_ERROR ... long error message...)
endfunction()
check_for_file(libFoo123.so Foo)
...
check_for_file(libBar123.so Bar)
I think the function approach is reasonable...
I don't like the overhead of a function.
Or I could collect the files and targets together, but then the error
message becomes less straigh forward.
You don't need the error message to do all the files at once. Just use
a foreach() to test them one at a time. Die on the first missing one.
In the meantime after Daves Ok I implemented the version using a function.
It works and is IMO ok. I pushed the branch, didn't merge it yet.
If I generate such a loop, I have to iterate over two lists in sync (one
containing the files, one containing the imported targets), since it should be
only once per file, and not once after each target.
This will also be not too pretty cmake code, something like
list(APPEND targets foo foo)
list(APPEND filenames libfoo.dll libfoo.lib)
...
list(APPEND targets bar)
list(APPEND filenames libbar.dll)
...
list(LENGTH length filenames)
set(index 0)
foreach(length)
list(GET index file filenames)
list(GET index target targets)
if (NOT EXISTS )
message(FATAL_ERROR )
endif()
math(EXPR index index + 1)
endforeach()
I'm not sure you'll like this version.
Maybe you'll prefer a more map-like implementation ?
list(APPEND _check_targets foo)
set(_filesToCheck_foo libfoo.dll libfoo.lib)
...
list(APPEND _check_targets bar)
set(_filesToCheck_bar libbar.dll libbar.lib)
...
foreach(target ${_check_targets} )
foreach(file ${_filesToCheck_${target}})
if (NOT EXISTS ${file})
message(FATAL_ERROR ...)
endif()
endforeach()
endforach()
So, if you are really not ok with the function as it is in the branch now
please let me know how you want to code to look like, so I need to change the
code only one more time.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] slow regex implementation in RegularExpression
On Wednesday 16 November 2011, Alexandru Ciobanu wrote: Hi Brad, ... Advantages of TRE: - API very similar to standard regex.h (i.e. easy to integrate with CMake) - supports wide characters - compiles on many platforms Windows, AIX, HP-UX, you name it. What do you think about TRE? http://laurikari.net/tre/about/ BSD licensed, gcc, IBM, HP; Sun compilers supported, also MSVC, including version 6. So from that side it looks good. Docs for the supported syntax: http://laurikari.net/tre/documentation/regex-syntax/ Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] slow regex implementation in RegularExpression
On Thursday 17 November 2011, Alexandru Ciobanu wrote:
Hi everyone,
[ CMake + TRE ]
I was able to make CMake use TRE, by changing the
RegularExpression.{cxx,hxx.in} files.
I ran the CMake tests, and 100% pass. See the attached log file.
(NOTE: Bootstrap, complex, complexOne were initially not aware of TRE
dependency, but I fixed that easily).
Cool :-)
[ Impact of using CMake + TRE on our builds ]
We picked one of our build machines and replaced the ctest binary on it.
The impact on the build time is pretty dramatic:
CMake: 7h39m
CMake + TRE: 1h06m
This is a machine that has two cores.
On machines that have more cores, the impact is even greater. On my 8 core
machine, running a particular build task: CMake:
19m57s
CMake + TRE: 1m30s
[ Regular expressions syntax ]
In terms of regular expressions syntax, the only difference that I've seen
is that TRE treats the curly brackets { and } as special characters,
because it uses them for its approximate matching. Details here:
http://laurikari.net/tre/documentation/regex-syntax/
The only CMake component that uses curly brackets in a regexp is:
Modules/FindJNI.cmake
but it was trivial to fix because they were used as mere delimiters.
Well, but there are cmake files out there (i.e. all existing cmake-based
projects) which also must behave basically exactly the same as before,
otherwise their builds might break.
Not sure how to achieve this.
A policy ?
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
On Wednesday 02 November 2011, David Faure wrote:
On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
On Monday 31 October 2011, David Faure wrote:
This is a typical (kde) case where the .cpp incudes the .moc, for the
object defined in the .h.
Shouldn't it include moc_kauthactionwatcher.cpp ?
No, that's for the case where the qobject is in the .cpp file.
Is this really a typical case, i.e. is that done in many places ?
Yes. Just grep for moc includes in kde...
I thought the rule is that if there is a include foo.moc, the Q_OBJECT
is in the same cpp file.
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, this was more or less
accidentially.
But it was the way kdesupport/automoc always worked, on purpose, not
accidentally.
OK, more precisely: it didn't care what the name of the included moc
file was, what mattered was, where is Q_OBJECT being used.
As the kde4automoc.cpp code says: when parsing the .cpp file:
// If the moc include is of the moc_foo.cpp style we expect the Q_OBJECT
class // declaration in a header file.
// If the moc include is of the foo.moc style we need to look for a
Q_OBJECT // macro in the current source file, if it contains the macro
we generate the // moc file from the source file, else from the header.
The logic which is currently implemented is:
1. if foo.cpp includes foo.moc, run moc on foo.cpp and generate foo.moc
That should depend on if foo.cpp actually says Q_OBJECT or not.
Otherwise this .moc should be created from the header file. Not much
point in running moc over a .cpp that doesn't define a Q_OBJECT :)
2. run moc on all header files bar.h which contain Q_OBJECT and
generate moc_bar.cpp from them
That could be moc_bar.cpp or bar.moc depending on which one is included.
(which in detail means:
2.1 for every included moc_xyz.cpp (no matter in which file), search
for a corresponsing xyz.h/hxx/hpp file and run moc on it
2.2 for every bar.cpp file, check whether there is a corresponding
bar.h/hpp/hxx file and collect it
2.3 check for a Q_OBJECT macro in all collected header files and all
header files listed explicitely as a source for the target, and run moc
on them. If the resulting moc_xyz.cpp file has not been included in any
source file, include it intargetname_automoc.cpp, which is built as
part of the target )
Step 2.2 already involves guessing, which I don't like.
Beside that, IMO these are clear rules, which are easy to understand.
With the old behaviour it was actually ambigous:
foo.h:
class Foo
{
Q_OBJECT
};
foo.cpp:
Foo::Foo() {}
#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 :-)
Now it is simple: foo.moc from foo.cpp, moc_foo.cpp from foo.h.
If this is really done in many places in KDE, I'll add some workaround,
but I think the default behaviour should stay as it is now in cmake
git.
How does qmake handle such cases ?
Checking
Indeed qmake expects moc_foo.cpp for the standard case (Q_OBJECT in
header). This is why kde4automoc was made to support both moc filenames,
so that it could be compatible with the kde way of doing it (foo.moc)
and with the qmake way of doing it (moc_foo.cpp).
Oh well, if you want to stick to that we'll change all of KDE, for the
benefit of a clearer future indeed... At least it won't be an source
incompatible change for app developers since they will have to enable
CMAKE_AUTOMOC to get into this situation. Merely upgrading cmake or KDE
(even to frameworks 5) won't trigger it. OK not exactly,
find_package(kde4) will stop working so they will -have- to port to
CMAKE_AUTOMOC, it will be the only solution available...
Please give the RestoreAutmocKDECompatibility branch on cmake stage a
try. It should work again, but print a warning if a file includes a
moc_foo.cpp, but no foo.moc, and contains a Q_OBJECT macro.
For Qt5 I'd prefer to not support that anymore.
I.e. moc_foo.cpp - header, foo.moc - source file.
Alex
I tried that branch.
I think I merged it into next in the meantime.
It doesn't build the frameworks branch for me. Does it work for you?
I haven't actually tried, I was relying on the frameworks developers (e.g.
you) for that :-)
In CMake/Tests/QtAutomoc/ there are several cases tested, actually I think all
I could think of.
Using Qt5 or Qt4 ?
There seems to be several problems:
* KDE does include foo.moc if it wants
Re: [cmake-developers] Multiple dependent install(EXPORT) sets
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 is writing library B's dependency on A, it can transform the name using the options that had been given to the install command for ExportA, such as its NAMESPACE. This is required because ExportB will create an imported target for library B and that imported target will list its dependency on an imported target for library A. What is that imported target called? Where is it defined? Only ExportA knows, and then only after its install(EXPORT) has been called. Yes. Where/why is it actually necessary to split libraries installed from one package into multiple Config.cmake files ? This is now to install separate libraries from a big kdelibs, right ? Maybe we (KDE) simply shouldn't do this, and just start with it once the big modules are broken into separate parts. Then each of the smaller parts can install a Config.cmake file for all its libraries. If e.g. libkgui depends on libkcore, currently those two targets would exist in one project, but installed as two export sets. Once they are separated into two projects, then libkgui depends already on the imported target KDE::kcore (or how it is named), and referencing this in its Targets.cmake file works fine. We do this already with Qt4. Furthermore, the targets file generated for ExportB will need to include() the file generated for ExportA using the DESTINATION given to the latter to make its targets available. And its FILE presumably, but why? This ties in to the question of whether find_package(B) should find the dependencies of B: We could leave this part out and leave it up to the Config.cmake file author to ensure ExportA's targets file is loaded when ExportB's targets file is loaded. Yes. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Stephen Kelly wrote: 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 in KDE use include moc_foo.cpp 'correctly', but there are only about 10 occurrences. The current automoc tool seems to handle that, as does cmake 2.8.6 apparently. I thought about this. There are 4 constellations, and only one constellation where things can break: * foo.cpp includes neither foo.moc nor moc_foo.cpp. No problem. Sort of. There are cases where the moc file must be included in the cpp file (see below). But this removal of includes is what we should aim for in KDE. I think if the options are: 1) Introduce odd hacky KDE specific workarounds to CMake 2) Remove the problematic includes from KDE files in the frameworks branch I will side with option 2). CMAKE_AUTOMOC is not used in KDE4. The feature is only really relevant to non KDE Qt4 users. Let's just 'fix the bug' in the frameworks iteration of kdelibs. * if foo.cpp includes both foo.moc and moc_foo.cpp, then both foo.h and foo.cpp will be moc'ed, and it doesn't matter which one is for which. No problem. It seems there is a test missing for this case. Yes. * if foo.cpp includes only foo.moc, then foo.cpp will be moc'ed. This may be unnecessary, but shouldn't create problems. If foo.h also needs to be moc'ed, it will be, and the resulting moc_foo.cpp will be included in the target_automoc.cpp file. So it should also work. This is Tests/QtAutomoc/codeeditor.cpp Sort of. There are cases where the moc file must be included in the cpp file, because it needs definitions from the .h file. (eg, use of the Q_PRIVATE_SLOT macro). I don't know that one. Are there docs somewhere ? I have also seen a I think Q_GADGET macro mentioned somewhere, but also didn't find docs. If they exist and require special handling, adding this special handling is fine IMO. If a KDE developer included foo.moc expecting that to be the result of moc'ing the .h file, the build will fail. In this case, foo.cpp needs to be fixed to include moc_foo.cpp instead. I don't think CMake should introduce a hack for this. * problematic case: if foo.cpp includes only moc_foo.cpp, then cmake will check whether foo.cpp contains Q_OBJECT. If it does, it will: ** fail with Qt5, stating that foo.cpp contains Q_OBJECT but does not include foo.moc, so it can't work I think this is fine. ** warn with Qt4 that it will run moc on foo.cpp instead of foo.h to generate moc_foo.cpp This is Tests/QtAutomoc/blub.cpp * KDE does include foo_test.moc in foo_test.cpp to moc the test object in foo_test.cpp. This is 'correct' compared to what qmake does. Yes. * KDE does eg, include kjob_p.moc in kjob.cpp to cause kjob_p.h to be moc'd. The RestoreAutmocKDECompatibility branch introduces a commit which makes this not work because the source file has a different basename. Yes. I did not expect somebody would be doing this. I don't want to support this for Qt5. I can add a fix with a warning for Qt4. This is not uncommon in both KDE and in Qt itself, or any other project where it makes sense to put a QObject-inherited class in the _p.h as an internally used class. See for example, qplaintextedit.cpp: #include moc_qplaintextedit.cpp #include moc_qplaintextedit_p.cpp This should be supported by the automoc feature. Yes, it should work. I'm adding a test. I have also seen places (I think in QtDeclarative) where a foo.cpp file included the file moc_bar.cpp, though that is very uncommon. The logic that I would use would be something like: find #include moc_(.*).cpp - generate moc for \\1.h This should work right now. I thought there is a test for this. Checking. 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 the including file, no ? I think we need to have a list of exactly what cases should be supported, This is the current documentation of automoc in cmake. I was hoping it would be relatively clear: If an #include statement like #include \moc_foo.cpp\ is found, the Q_OBJECT class declaration is expected in the header, and moc is run on the header file. If an #include statement like #include \foo.moc\ is found, then a Q_OBJECT is expected in the current source file and moc is run on the file itself. Additionally, all header files are parsed for Q_OBJECT macros, and if found, moc is also executed on those files. The resulting moc files, which are not included as shown above in any
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Alexander Neundorf wrote: On Tuesday 22 November 2011, Stephen Kelly wrote: ... This is not uncommon in both KDE and in Qt itself, or any other project where it makes sense to put a QObject-inherited class in the _p.h as an internally used class. See for example, qplaintextedit.cpp: #include moc_qplaintextedit.cpp #include moc_qplaintextedit_p.cpp This should be supported by the automoc feature. Yes, it should work. I'm adding a test. 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). I have also seen places (I think in QtDeclarative) where a foo.cpp file included the file moc_bar.cpp, though that is very uncommon. The logic that I would use would be something like: find #include moc_(.*).cpp - generate moc for \\1.h This should work right now. I thought there is a test for this. Checking. Test added, works. Can you please update from this branch and see what testcases are missing in QtAutomoc/Tests/ ? Thanks Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Multiple dependent install(EXPORT) sets
On Tuesday 22 November 2011, Stephen Kelly wrote: 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 is writing library B's dependency on A, it can transform the name using the options that had been given to the install command for ExportA, such as its NAMESPACE. This is required because ExportB will create an imported target for library B and that imported target will list its dependency on an imported target for library A. What is that imported target called? Where is it defined? Only ExportA knows, and then only after its install(EXPORT) has been called. Yes. Where/why is it actually necessary to split libraries installed from one package into multiple Config.cmake files ? This is now to install separate libraries from a big kdelibs, right ? Maybe we (KDE) simply shouldn't do this, and just start with it once the big modules are broken into separate parts. Maybe. Should nobody install multiple 'modular pieces' from one top level CMakeLists.txt? It's sort of superbuild without superbuild, but with the advantage that the sources are in the source directory. Yes, maybe, but this was not initially the goal, so that doesn't work right now. The motivation for exporting multiple sets of targets from one project was (at least among others) to be able to export libraries and executables separately. This way when crosscompiling, the crosscompiled project can import the executable targets from a native build, and do e.g. get_target_property(LOCATION ) on the imported executable target the same way it can do that in the native build where it has really built the executable. Also executable targets are recognized as commands in add_custom_command() and add_custom_executable(), so you can simply use the target name there and don't have to care whether it is an imported executable target from a native build or whether you are natively building. For that purpose splitting the libraries into multiple dependend sets was not necessary (which doesn't mean it would be a bad thing). Then each of the smaller parts can install a Config.cmake file for all its libraries. If e.g. libkgui depends on libkcore, currently those two targets would exist in one project, but installed as two export sets. Once they are separated into two projects, then libkgui depends already on the imported target KDE::kcore (or how it is named), and referencing this in its Targets.cmake file works fine. Does a target know its imported target name or is it really just the export mechanism? It's only in the export sets. You can also put a target into multiple export sets, with different namespaces etc. if you want to. With that, one exported target doesn't know which of the potentially multiple names of the exported target it depends on it should use. Would it be possible for the export mechanism to inform the targets of their imported target name and location so that that information can be retrieved by dependents? Consider this: add_library(bar) add_library(foo) target_link_libraries(foo bar) install(TARGETS bar EXPORT barTargets ...) install(TARGETS foo EXPORT fooTargets ...) install(EXPORTS barTargets NAMESPACE myNS) # sets a property on bar that its # imported name is myNS::bar install(EXPORTS barTargets NAMESPACE myNS2) #didn't test but I think it works install(EXPORTS fooTargets NAMESPACE otherNS) # Maps from the LINK_LIBRARIES # information 'bar' to # 'myNS::bar' to populate the # dependency information # or myNS2 ? ... This also removes the need for explicit dependencies between install(EXPORTS) invocations, which is already implicitly specified by the (public) link interface of targets build in the same build system. We do this already with Qt4. You mean in FindQt4.cmake? I'm not sure it's the same situation. I was talking about the following: FindQt4.cmake creates imported targets. In kdelibs we link against them. The names of the imported targets from Qt4 appear again in the Targets.cmake file for kdelibs: # Import target KDE4__kdecore for configuration RelWithDebInfo ... SET_TARGET_PROPERTIES(KDE4__kdecore PROPERTIES IMPORTED_LINK_INTERFACE_LIBRARIES_RELWITHDEBINFO Qt4::QtDBus;Qt4::QtCore;- lpthread IMPORTED_LOCATION_RELWITHDEBINFO /home/alex/Dashboards/installs/2.8.1/kdelibs/lib/libkdecore.so.5.5.0 IMPORTED_SONAME_RELWITHDEBINFO libkdecore.so.5 ) In FindKDE4Internal.cmake we do find_package(Qt4), which creates the imported
Re: [cmake-developers] cmake automoc breaks kde
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 a moc_foo.cpp, but no foo.moc, and contains a Q_OBJECT macro. For Qt5 I'd prefer to not support that anymore. I.e. moc_foo.cpp - header, foo.moc - source file. Alex I tried that branch. It doesn't build the frameworks branch for me. I found the mistake ! When I wrote that mail two weeks ago it was the RestoreAutmocKDECompatibility branch. This got merged into master in the meantime. Once your Qt5 branch was merged, I created a new branch named AutomocIncludedDotMocFileHandling. This is the branch I'm talking about. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 0/3] The CMake Ninja generator.
On Tuesday 22 November 2011, Peter Collingbourne wrote: On Tue, Nov 15, 2011 at 06:54:01PM +0100, Nicolas Desprès wrote: On Tue, Nov 15, 2011 at 5:29 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 11/11/2011 9:36 PM, Peter Collingbourne wrote: Note that this generator is *nix only (it relies on POSIX shell functionality), and will only be built on *nix platforms. I am not interested in Windows support, but I understand that others have expressed an interest in adding support. How much of the POSIX shell stuff can be done with cmake -E stuff? It would be good to use as little POSIX stuff as possible as someday when someone does the inevitable windows port it is easier... Too much in my opinion. Specially the operator of the shell. Using cmake -E is the first step. I am planning to suggest an evolution of Ninja to fix this issue. Actually, it is the main issue which stop me while writing the beginning of this generator. Other than we also have: rm -f $file -- used to delete static library archives before rebuilding cmake -E remove -f $file : -- used as a no-op command maybe cmake -E echo Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Stephen Kelly wrote: 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 a moc_foo.cpp, but no foo.moc, and contains a Q_OBJECT macro. For Qt5 I'd prefer to not support that anymore. I.e. moc_foo.cpp - header, foo.moc - source file. Alex I tried that branch. It doesn't build the frameworks branch for me. I found the mistake ! When I wrote that mail two weeks ago it was the RestoreAutmocKDECompatibility branch. This got merged into master in the meantime. Once your Qt5 branch was merged, I created a new branch named AutomocIncludedDotMocFileHandling. This is the branch I'm talking about. Alex Actually I've been using that branch all along. I noticed I slightly got confused by all the branches, sorry. 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 from a different source file. This is not supported. Include kdirwatch.moc to run moc on this source file. I added special handling now for the case that basename_p.moc is included with Qt4. I then get a good deal of /home/stephen/dev/src/kf5/tier1/libkauth/HelperProxy.cpp:0: Note: No relevant classes found. No output generated. Generating FakeHelperProxy.moc /home/stephen/dev/src/kf5/tier1/itemmodels/src/kcheckableproxymodel.cpp:0: Note: No relevant classes found. No output generated. Generating moc_kdescendantsproxymodel.cpp /home/stephen/dev/src/kf5/tier1/libkauth/backends/fakehelper/FakeHelperProx y.cpp:0: Note: No relevant classes found. No output generated. The warnings are good because they indicate doing it the wrong way. As I noted in the other mail, I'll fix these issues in the frameworks branch. Do you want testcases for them in cmake to workaround it there? Please have a look at the current AutomocIncludedDotMocFileHandling branch and see if there are still things missing. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] slow regex implementation in RegularExpression
On Wednesday 23 November 2011, David Cole wrote:
On Wed, Nov 23, 2011 at 2:09 PM, David Cole david.c...@kitware.com wrote:
On Wed, Nov 23, 2011 at 2:03 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 11/23/2011 12:51 PM, Brad King wrote:
On 11/23/2011 12:48 PM, Brad King wrote:
On 11/23/2011 12:43 PM, Brad King wrote:
On 11/23/2011 12:34 PM, Alexandru Ciobanu wrote:
The regex in question is:
^[^][:/*?]+\$
To include a literal ] in the list, make it either the first item
It must be the [: in this regex that TRE sees as special since it
allows expressions like [:digit:] inside a bracket expression.
Still, this is a case that my proposed policy would pick up.
-Brad
I am still very wary about this policy. For 99% of folks the current
regex is just fine. Making them eventually change to get the new
regex is making them do work that they don't need or want. I would
rather have two API's. I just don't see the big upside of TRE, and I
see this causing pain for lots and lots of folks if we push them to
make the change. CMake has most likely 100,000 or more users at this
point. A change like this could easily inflict a man years of effort
onto the world, and should not be taken lightly.
-Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Big upside:(quoting from Alexandru Ciobanu's email of Nov. 17th
earlier in this thread)
The impact on the build time is pretty dramatic:
CMake: 7h39m
CMake + TRE: 1h06m
And although there is a big upside, we do still have to be careful.
We have to remember that regexes are used in the context of ctest -D
invocations, ctest -S script running and cmake -P running, too, where
policies are not really a reliable mechanism. So in addition to having
a careful policy, we also have to decide what to do in those cases.
The case that is in question here for the big performance gain is
ctest running and filtering build output based on regexes. No cmake
policy mechanism in sight for that scenario.
Also, AFAIK supports more stuff than the current regexps. This is good.
But doesn't that mean that potentially there could be regexps existing which
right now don't have a special meaning, but with TRE they suddenly get a
special meaning and change the matching ?
Does e.g. the following produce the same result ? I get : as match here.
set(text hello world [:digit:])
if (${text} MATCHES .+([:digit:]))
message(STATUS match: \${CMAKE_MATCH_1}\)
endif()
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating imported library targets without the cmake executable
On Thursday 24 November 2011, 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.
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 that is not the case. Additionally, as the Qt buildsystem
knows everything about the package it is creating, it is possible to
create config files that already 'know the answers' and locations of
everything without having to find+query.
The previous discussion on this is here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2090
the current candidate for inclusion in Qt is here (which requires an
account in the Qt jira):
http://codereview.qt-project.org/#change,8518
and here (which does not):
https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-
qtbase/commit/913fd3a1acffbae2ca8f6967dd951a03ff9f76a4
There is a small sticking point to this being in a finished state:
In creating the imported targets, I attempt to create the same content as
cmake creates when using install(EXPORTS). So I generate something along
these lines:
get_filename_component(_qt5_install_prefix
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
set_property(TARGET Qt5Core APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
set_target_properties(Qt5Core PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG
IMPORTED_LOCATION_DEBUG ${_qt5_install_prefix}/lib/libQtCore.so.5.0.0
IMPORTED_SONAME_DEBUG libQtCore.so.5
)
set_property(TARGET Qt5Core APPEND PROPERTY IMPORTED_CONFIGURATIONS
RELEASE) set_target_properties(Qt5Core PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE
IMPORTED_LOCATION_RELEASE
${_qt5_install_prefix}/lib/libQtCore.so.5.0.0
IMPORTED_SONAME_RELEASE libQtCore.so.5
)
That is, I generate the full file name for the IMPORTED_LOCATION including
the library prefix and suffix, which are also used for the IMPORTED_SONAME.
QMake does not provide the library prefix and suffix used in variables, as
cmake does, but I believe there is also no way to change them in qmake. As
a result I hardcode the prefixes and suffixes for windows/linux/max -
.dll, .so etc.
The Qt QMake maintainer does not like this, and requests that CMake
determines the prefix and suffix instead. Does CMake provide any way for me
to get the default prefix and suffix for libraries? If it does then I could
generate something like this instead:
IMPORTED_SONAME ${CMAKE_LIBRARY_PREFIX}QtCore.${CMAKE_LIBRARY_SUFFIX}.5
It's CMAKE_(STATIC|SHARED)_LIBRARY_(SUFFIX|PREFIX) .
But I still don't think it's necessarily a good idea or the right change to
make. QMake and CMake don't necessarily agree on what the prefix and suffix
for libraries will be on different platforms for one thing.
Yes, it would be the wrong source of information. This information must come
from the one who creates libraries, not from the one who wants to know how
they are named.
What would you consider a good idea?
Could this have any implications for cross-compiling?
Currently I generate IMPORTED_CONFIGURATIONS for debug and release
(conditionally, depending on how Qt is built). Should I also generate code
to set target properties for no configuration? Or should I only do that,
and not have debug/release versions?:
Having a debug configuration is a good thing I'd say.
Additionally having a release or noconfig version should be fine.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating imported library targets without the cmake executable
On Friday 25 November 2011, Stephen Kelly wrote: 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/+kdab-developers/qt/kdab-developers-qtbase/ the branch is cmake_files. The testing steps are: 1) build and install Qt 2) cd qtbase/tests/manual/cmake 3) mkdir build cd build 4) cmake .. make 5) No error reported == success. Could you maybe put the generated .cmake files somewhere ? This would save hours in downloading, compiling etc. I think you'll get more and quicker feedback then. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating imported library targets without the cmake executable
On Friday 25 November 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Friday 25 November 2011, Stephen Kelly wrote: 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/+kdab-developers/qt/kdab-developers-qtbase/ the branch is cmake_files. The testing steps are: 1) build and install Qt 2) cd qtbase/tests/manual/cmake 3) mkdir build cd build 4) cmake .. make 5) No error reported == success. Could you maybe put the generated .cmake files somewhere ? This would save hours in downloading, compiling etc. I think you'll get more and quicker feedback then. 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 :-) Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories branch in stage
...a somewhat related idea: if it will be possible to set include directories per target, and since it is already possible to set compile flags per target, it would be nice if I could also set a property on targets which keeps them from using the global settings at all. Something like set_target_properties(hello PROPERTIES COMPILE_FLAGS ... INCLUDE_DIRS ... IGNORE_GLOBAL_SETTINGS TRUE) which would have the effect that neither the include directories for the current directory nor the global CMAKE_(C|CXX)_FLAGS would be used, but only what has been explicitely set for this target. Sounds like a useful idea ? If you think it makes sense, I might have some time to work on it. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Stephen Kelly wrote: 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 from a different source file. This is not supported. Include kdirwatch.moc to run moc on this source file. I added special handling now for the case that basename_p.moc is included with Qt4. Your new commits work with the parts of the frameworks branch affected by this, yes. However, there are still many places where the foo.moc file is expected to be the result of moc'ing the header, which causes errors like this: In file included from /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/kdbus_automoc.cpp:2:0: /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.c pp: In static member function 'static void KDBusInterProcessLock::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)': /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.c pp:55:22: error: invalid use of incomplete type 'struct KDBusInterProcessLockPrivate' /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/../../../../../src/kf5/tie r1/libkdbus/kdbusinterprocesslock.h:30:7: error: forward declaration of 'struct KDBusInterProcessLockPrivate' Fixed by changing the include from foo.moc to moc_foo.cpp of course. This is due to the use of Q_PRIVATE_SLOT. I've just added a testcase to the branch. Please give the current AutomocIncludedDotMocFileHandling branch a try, it checks now also for this. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating imported library targets without the cmake executable
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 help :-) I managed to get generated files for windows and mac through some IRC puppeteering, so I've attached them here now. Thanks, I looked through the QtCore files. Some things: if (NOT _Qt5Core_target) set(_Qt5Core_target 1) add_library(Qt5Core SHARED IMPORTED) if (NOT STREQUAL ) set_property(TARGET Qt5Core PROPERTY FRAMEWORK 1) endif() endif() I think you can simply do: if(NOT TARGET Qt5Core) add_library(Qt5Core SHARED IMPORTED) if (NOT STREQUAL ) set_property(TARGET Qt5Core PROPERTY FRAMEWORK 1) endif() endif() Can this also handle already static builds of Qt ? Why do you have an if() around including Qt5CoreMacros.cmake and Qt5CoreConfigExtras.cmake ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating imported library targets without the cmake executable
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 it to be consistent.
So should I rename them or should I instead add
set(Qt5Core_LIBRARIES ${Qt5Core_LIBRARY})
This convention is only used in Find modules to collect the individual
find results. In the Config modules you already know the complete list
so you can go straight to the plural name.
Yes.
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 do that, and then maybe do
something with the target name.
This is harder if there is only the plural version of the variables.
I'd say those singular versions are not strictly necessary, but they don't
hurt and can in some cases be useful.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating imported library targets without the cmake executable
On Wednesday 30 November 2011, 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 or override. In a Config.cmake file we know the answer. Ok, so you're saying the user should definitely not be able to override the value, so it shouldn't be cached. The remaining question is whether it should be provided anyway uncached for the reasons Alex described. If that should be done, then I can do that. I don't mind providing it for convenience. However more variables means more variables. Users may not know which one to use when. I don't have a strong opinion either way. Ok, my opinion is to provide one variable in plural form for now. If there is a reason to provide a singular form, we can add that later. Let's just see what Alex and CLinton say before I do that. I'd provide also the singular forms, but I don't have a strong opinion on it. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating imported library targets without the cmake executable
On Wednesday 30 November 2011, Stephen Kelly wrote: 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 help :-) I managed to get generated files for windows and mac through some IRC puppeteering, so I've attached them here now. Thanks, I looked through the QtCore files. Some things: if (NOT _Qt5Core_target) set(_Qt5Core_target 1) add_library(Qt5Core SHARED IMPORTED) if (NOT STREQUAL ) set_property(TARGET Qt5Core PROPERTY FRAMEWORK 1) endif() endif() I think you can simply do: if(NOT TARGET Qt5Core) add_library(Qt5Core SHARED IMPORTED) if (NOT STREQUAL ) set_property(TARGET Qt5Core PROPERTY FRAMEWORK 1) endif() endif() I didn't do it like this because that could potentially hide errors as described here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2147/focus =2152 Someone else could define a target called QtCore (in theory at least), and it makes sense to show a failure as early as possible. Hmm, ok. Somebody could also have set that variable already... ;-) For Qt4 I have put the imported targets into a namespace Qt4::, so they are e.g. Qt4::QtCore. It looks nice and it makes somewhat clear that Qt5Core is not the name of an in-project target, or the name of a library to link against, but something special (an imported target). I'd do that here too, so it would be Qt5::Qt5Core etc. This also reduces the risk of name clashes even more. Can this also handle already static builds of Qt ? Nope, not yet. 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 ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories branch in stage
On Wednesday 30 November 2011, Brad King wrote: On 11/29/2011 2:28 PM, Alexander Neundorf wrote: ...a somewhat related idea: if it will be possible to set include directories per target, and since it is already possible to set compile flags per target, it would be nice if I could also set a property on targets which keeps them from using the global settings at all. The design for the new INCLUDE_DIRECTORIES property allows this. After the last include_directories() call in a directory one may set the INCLUDE_DIRECTORIES property of any target to anything and overwrite whatever came from the directory. Cool :-) In the current design the property is initialized when the target is created to the current directory-level value. Then each additional include_directories() call appends to the dir-level value *and* the targets in the directory. Perhaps the latter could be disabled by a property like you propose. Especially I'd be interested in having that for the compile flags. I'm not sure whether a disable all global or directory level settings would be enough or whether it should be fine-grained so that e.g. compile flags and include dirs could be disabled separately. Probably also link_directories() and link_libraries() (but they are more rarely used). Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Wednesday 30 November 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Tuesday 22 November 2011, Stephen Kelly wrote: 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 from a different source file. This is not supported. Include kdirwatch.moc to run moc on this source file. I added special handling now for the case that basename_p.moc is included with Qt4. Your new commits work with the parts of the frameworks branch affected by this, yes. However, there are still many places where the foo.moc file is expected to be the result of moc'ing the header, which causes errors like this: In file included from /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/kdbus_automoc.cpp:2:0: /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.c pp: In static member function 'static void KDBusInterProcessLock::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)': /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.c pp:55:22: error: invalid use of incomplete type 'struct KDBusInterProcessLockPrivate' /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/../../../../../src/kf5/tie r1/libkdbus/kdbusinterprocesslock.h:30:7: error: forward declaration of 'struct KDBusInterProcessLockPrivate' Fixed by changing the include from foo.moc to moc_foo.cpp of course. This is due to the use of Q_PRIVATE_SLOT. I've just added a testcase to the branch. Please give the current AutomocIncludedDotMocFileHandling branch a try, it checks now also for this. Building solid still fails with the AutomocIncludedDotMocFileHandling branch. One of the reasons for failure is including a file with a different basename .moc. Fixed in solid with -#include devicenotifier.moc +#include moc_devicenotifier.cpp in devicemanager.cpp. The other failure is building files in subdirectories from a CMakeLists two levels up (all the files in the subdirectories are compiled into a single library) and including their moc files, which fails. /home/stephen/dev/src/kf5/tier1/solid/solid/backends/fakehw/fakedevice.cpp: 338:42: fatal error: backends/fakehw/fakedevice.moc: No such file or directory Solid builds standalone with Qt 4 in the frameworks branch. You already have it in your kdelibs git repo. The easiest thing would be: git new-workdir kdelibs kdelibs-frameworks frameworks cd kdelibs-frameworks/tier1/solid mkdir build cd build cmake .. make For convenience I put the current solid source here: http://www.steveire.com/share/solid.tar.gz 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 @@ Solid::AudioInterface::SoundcardType Solid::AudioInterface::soundcardType() cons return_SOLID_CALL(Ifaces::AudioInterface *, d-backendObject(), InternalSoundcard, soundcardType()); } -#include audiointerface.moc +#include moc_audiointerface.cpp An alternative way to fix this is to include QVariant in the header and not include the moc file here at all. - diff --git a/tier1/solid/solid/backends/fakehw/fakedevice.cpp b/tier1/solid/solid/backends/fakehw/fakedevice.cpp index dce82e4..1e5781a 100644 --- a/tier1/solid/solid/backends/fakehw/fakedevice.cpp +++ b/tier1/solid/solid/backends/fakehw/fakedevice.cpp @@ -335,5 +335,5 @@ QObject *FakeDevice::createDeviceInterface(const Solid::DeviceInterface::Type t return iface; } -#include backends/fakehw/fakedevice.moc +#include backends/fakehw/moc_fakedevice.cpp #include backends/fakehw/fakedevice_p.moc This one was actually a bug, this one works now with the updated branch. - diff --git a/tier1/solid/solid/devicemanager.cpp b/tier1/solid/solid/devicemanager.cpp index 06919c3..0fd8c89 100644 --- a/tier1/solid/solid/devicemanager.cpp +++ b/tier1/solid/solid/devicemanager.cpp @@ -288,6 +288,6 @@ void Solid::DeviceManagerStorage::ensureManagerCreated() } } -#include devicenotifier.moc +#include moc_devicenotifier.cpp #include moc_devicemanager_p.cpp In this case at least the error message is early and to the point: AUTOMOC: error: /home/alex/src/CMake/tests/solid/solid/devicemanager.cpp: The file includes the moc file devicenotifier.moc, which seems to be the moc file from a different source file. This is not supported. Include devicemanager.moc to run moc on this source file. An alternative fix is the following: diff -rbup solid.orig/solid//solid/CMakeLists.txt solid//solid/CMakeLists.txt --- solid.orig/solid//solid
Re: [cmake-developers] cmake automoc breaks kde
On Thursday 01 December 2011, Stephen Kelly wrote: 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 @@ Solid::AudioInterface::SoundcardType Solid::AudioInterface::soundcardType() cons return_SOLID_CALL(Ifaces::AudioInterface *, d-backendObject(), InternalSoundcard, soundcardType()); } -#include audiointerface.moc +#include moc_audiointerface.cpp An alternative way to fix this is to include QVariant in the header and not include the moc file here at all. Personally I prefer fixing the moc include so that it's still possible to forward declare in the header file. It is very common to forward declare in KDE. I don't know how likely this is to occur though. However, including the correct include file is an easy fix. We can start the updating of the KDE moc strategy soon I think. 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 the result in basename.moc', or does that conflict with another rule? I'll put some more work in it over the weekend. Probably something like this should work. Or if it's not my own .moc-file, never assume it's the .moc-file from another cpp-file (end of story here with Qt5), but try whether it could be the moc- file from a header. ... So I think with the current cmQtAutomoc::ParseCpp() I can't handle and can't detect and warn for those cases. Which would mean that automoc in 2.8.7 will not be able to substitute the standalone automoc4 (as 2.8.6 was). This is not really good. But at least now in 2.8.7 automoc behaves more like what the documentation said already in 2.8.6, so it could be argued that everything which was working before is still working now and everything which does not work anymore was working only by accident. Which seems kind of ok, Yes, I think the situation is pretty good with it now, though we haven't tried to build the rest of KDE with it. Let me know how it works. 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 cmake requirement for it, but that's more a topic for kde-buildsystem. If you really meant frameworks branch, then I'd say we fix solid and move on. No, I meant kdelibs4. Still people will continue to build against it for some time (it's not even dead yet), and the cmake stuff in it should stay maintained. This would be easier if there was only one group of files (the ones in e-c-m), instead of two (kdelibs4 and e-c-m). See the mail for the FindQtMobility.cmake review... ... There are a great deal of warnings like: /home/stephen/dev/src/grantlee/templates/lib/template.cpp:0: Note: No relevant classes found. No output generated. because moc is run on the cpp file (it is also run on the header of course). Is it possible to give a better warning from cmake in those cases? If not, it's probably a big deal. not a big deal, right ? The solution is just to remove the .moc includes anyway. Yes. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Thursday 01 December 2011, David Cole wrote: ... You have two topics on the stage with common parent commits: AutomocIncludedDotMocFileHandling (not presently in next) and RestoreAutmocKDECompatibility (which is presently in next)... Are you planning to keep both of these, or are you focused on the continuing topic AutomocIncludedDotMocFileHandling with the intention of removing RestoreAutmocKDECompatibility from the stage...? I'll remove the RestoreAutmocKDECompatibility branch tomorrow, AutomocIncludedDotMocFileHandling should contain everything (I got a bit confused with the branches two weeks ago). Is that ok or will that create problems with merging etc ? Also, could you remove TI_DSP_Compiler from the stage, and use some other mechanism (github, gitorious, ...) to communicate changes with the guy on the other side of that branch? The topic stage should really only be used for things that are intended for 'next' in the near future. Brad and I don't want to get in the habit of ignoring old topic branches week after week when we review stuff on the stage. Hmm, ok. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Friday 02 December 2011, Stephen Kelly wrote: 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 the result in basename.moc', or does that conflict with another rule? I'll put some more work in it over the weekend. Probably something like this should work. Or if it's not my own .moc-file, never assume it's the .moc-file from another cpp-file (end of story here with Qt5), but try whether it could be the moc- file from a header. Please make the behaviour difference not determined by Qt4 vs Qt5 but by a variable. That is, please make: find_package(Qt4) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOMOC_STRICT ON) behave with what you call the 'Qt5' behaviour, and find_package(QtCore 5) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOMOC_STRICT OFF) behave with what you call the 'Qt4' behaviour. That is, introduce a CMAKE_AUTOMOC_STRICT variable to control which mode the automoc stuff works with, and have a different default between Qt4 and Qt5, but allow overriding that default. Porting to Qt5 (for KDE at least) needs to eb a multi-step process for applications depending on kdelibs (and this feature). I think it needs to be possible to run automoc in non-strict mode with Qt5. Please try the current AutomocIncludedDotMocFileHandling branch. It now accepts even more included .moc files. It also builds solid as it is, but you get a whole lot of warnings. Without commit 40c516783e1df141f3d4a8 solid doesn't build, it fails with the included AudioDevice.moc file, but this patch also causes the many warnings mentioned above. The switch variable is called CMAKE_AUTOMOC_STRICT_MODE. Docs and a test are still missing. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories branch in stage
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 release. That seems unlikely to happen. If RC1 is Wednesday, it would have to be clean on the dashboard by then, which means cleanup of issues reported by the nightlies on Tuesday, which means putting it in next on Monday in order to get the nightlies generated. I've pushed the branch to my gitorious clone again. https://gitorious.org/~steveire/cmake/steveires-cmake The top two commits need to be reviewed and have real fixes decided and written for them. Should the memoization be removed? What does cmMakeDepends do? Note that if the goal is to merge this into next on Monday, there is little point explaining this to me and asking me to make the necessary changes. That would be too inefficient. git reset HEAD^^ and doing the fixes would be better. Additionally, the generators for XCode and VisualStudio don't build in the branch (though I haven't tried) because I changed the signature of LocalGenerator::GetIncludeDirectories. Again, that would have to be fixed by someone with direct access to those platforms and/or generators. Finally, the Eclipse generator builds, and all tests pass, which means mostly that I don't know how to test it. I didn't port it away from cmMakefile::GetIncludeDirectories, and yet the (updated) IncludeDirectories test passes. I expected the test to fail. To run the test I did: mkdir eclipse_gen cd eclipse_gen cmake .. -G Eclipse CDT4 - Unix Makefiles make ./bin/ctest The Eclipse generator generates Makefiles, and additionally Eclipse project files. But those are not tested during the tests, only the makefiles are tested. I don't know of any way to test automatically whether an Eclipse project works (except loading it manually). What could be broken there ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fwd: How to handle different cmake versions in extra-cmake-modules ?
On Tuesday 06 December 2011, Brad King wrote: On 12/6/2011 1:13 PM, Alexander Neundorf wrote: Does that look like it should cover all use cases, for peopling wanting to selectively use some things from e-c-m, and fearing that something would break if they simply would make everything available ? That proposal looks good to me. As an additional suggestion, I think you should always use an ECM version number so people get used to writing it. That way projects can ensure they get a compatible version of ECM: find_package(extra-cmake-modules 1.2 REQUIRED) Do you mean the version number should be enforced ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fwd: How to handle different cmake versions in extra-cmake-modules ?
On Tuesday 06 December 2011, Alexander Neundorf wrote:
Hi,
On Monday 07 November 2011, Brad King wrote:
On 11/6/2011 6:12 AM, Stephen Kelly wrote:
ecm_copy_modules(${CMAKE_BINARY_DIR}/modules FindFoo.cmake
FindBlub.cmake
ECMDoSomething.cmake)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
${CMAKE_BINARY_DIR}/modules} )
This macro would copy just these needed files into the given directory,
which can then be added to CMAKE_MODULE_PATH.
See below for an idea that may solve cases 2 and 3 together.
Case 3. I don't really have an idea yet. Add some code at the top of
each file which include()s the file from cmake if the version is
bigger than some specified version ?
Something like:
FindBlub.cmake:
if(CMAKE_VERSION 2.8.12)
include(${CMAKE_ROOT}/Modules/FindBlub.cmake)
return()
endif()
We've done the following before:
if(EXISTS ${CMAKE_ROOT}/Modules/FindBlub.cmake)
include(${CMAKE_ROOT}/Modules/FindBlub.cmake)
return()
endif()
That way you don't need to know when the module is added. It is also
forward-compatible for any module not yet in CMake but may be later.
OTOH the version of the module added to CMake may provide a slightly
different interface than the original version. That leads to the
unfortunate situation that a newer CMake breaks an existing build,
which looks like CMake's fault but isn't.
Another option is to provide a function that generates forwarding
modules. Instead of ecm_copy_modules, create a similar API that
generates short modules that include either the ECM version or the
CMake version depending on some conditions. Do the inclusion by
full path so that the actual ECM module dir does not need to be in
the CMAKE_MODULE_PATH.
yesterday in the train I found the time to do start with something on this.
So, here is the idea:
* the files containing macros/functions and the find-modules are put into
two different directories, e.g. modules/macros/ and modules/find/.
(Since the macros will all have the ecm_ prefix, a clash with anything
from cmake is not possible. So we only have to care about the
Find-modules.) So when doing
find_package(extra-cmake-modules)
two variables will be defined, ECM_MACROS_DIR and ECM_FIND_MODULES_DIR.
If somebody wants everything, he does
set(CMAKE_MODULES_PATH ${ECM_MACROS_DIR} ${ECM_FIND_MODULES_DIR} )
If he wants to use only some macros, he does
set(CMAKE_MODULES_PATH ${ECM_MACROS_DIR} )
If he wants to use a subset of the find-modules, there is a function
ecm_use_find_modules:
ecm_use_find_modules(DIR destdir
MODULES FindFoo.cmake FindBar.cmake ...
[NO_OVERRIDE] )
The listed find-modules will be copied from ${ECM_FIND_MODULES_DIR} to the
directory given here as destination dir, and this directory has to be added
to CMAKE_MODULE_PATH.
If NO_OVERRIDE is used, the files will only be used if they do not exist in
cmake.
This way e.g. FindBlub.cmake will be used until it is part of cmake, then
the cmake version will be used.
Attached is a draft of the file, just to show the idea, I didn't actually
try to run it yet.
Examples:
1) use everything from e-c-m:
find_package(extra-cmake-modules REQUIRED)
set(CMAKE_MODULE_PATH ${ECM_MACROS_DIR} ${ECM_FIND_MODULES_DIR} )
2) make all macros available, but no find-modules:
find_package(extra-cmake-modules REQUIRED)
set(CMAKE_MODULE_PATH ${ECM_MACROS_DIR} )
3) make all macros available and some find-modules if they do not yet exist
in cmake:
find_package(extra-cmake-modules REQUIRED)
ecm_use_find_modules(DIR ${CMAKE_CURRENT_BINARY_DIR}/ecm/
MODULES FindFoo.cmake NO_OVERRIDE)
set(CMAKE_MODULE_PATH ${ECM_MACROS_DIR} ${CMAKE_CURRENT_BINARY_DIR}/ecm/ )
4) make all macros available and some find-modules as override for the
cmake ones:
find_package(extra-cmake-modules REQUIRED)
ecm_use_find_modules(DIR ${CMAKE_CURRENT_BINARY_DIR}/ecm/
MODULES FindBoost.cmake)
set(CMAKE_MODULE_PATH ${ECM_MACROS_DIR} ${CMAKE_CURRENT_BINARY_DIR}/ecm/ )
Does that look like it should cover all use cases, for peopling wanting to
selectively use some things from e-c-m, and fearing that something would
break if they simply would make everything available ?
I added this now to extra-cmake-modules:
http://quickgit.kde.org/?p=extra-cmake-
modules.gita=blobhb=HEADf=modules/ECMUseFindModules.cmake
The find-modules now go into find-modules/, other modules go into modules/.
Alx
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe
[cmake-developers] Adding macro cmake_print_variables(var1 var2 ... varN) ?
Hi,
I have a small macro/function which I need often during buildsystem debugging:
function(PRINT_VARIABLES)
set(msg )
foreach(var ${ARGN})
if(msg)
set(msg ${msg} ; )
endif()
set(msg ${msg}${var}=\${${var}}\)
endforeach()
message(STATUS ${msg})
endfunction()
it prints the values of the variables given as arguments.
Example:
print_variables(CMAKE_C_COMPILER
CMAKE_MAJOR_VERSION
THIS_ONE_DOES_NOT_EXIST)
Gives:
-- CMAKE_C_COMPILER=/usr/bin/gcc ; CMAKE_MAJOR_VERSION=2 ;
THIS_ONE_DOES_NOT_EXIST=
Ok to add to git ?
Or should this better be
message(VARIABLES CMAKE_C_COMPILER
CMAKE_MAJOR_VERSION
THIS_ONE_DOES_NOT_EXIST)
Or not at all ?
Then I'll put it in extra-cmake-modules, but it seems to generic that I think
it makes sense to have it in cmake directly.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] A few more changes to automoc before 2.8.7
Hi, in current CMake HEAD automoc has two modes: strict and not strict. In strict mode it is behaves exactly how the documentation says: If an #include statement like #include moc_foo.cpp is found, the Q_OBJECT class declaration is expected in the header, and moc is run on the header file. If an #include statement like #include foo.moc is found, then a Q_OBJECT is expected in the current source file and moc is run on the file itself. In non-strict mode it accepts more, which makes it kdelibs4-compatible. The strict mode should be qmake-compatible AFAIK. Currently, if Qt4 is detected CMAKE_AUTOMOC_STRICT_MODE is initialized to FALSE, if Qt5 is detected it is initialized to TRUE. I'd like to change that so that it is always initialized to TRUE, so everybody gets strict mode by default (which is easier to understand). Then, if STRICT mode is default, I'm thinking about inverting the variable, i.e. from CMAKE_AUTOMOC_STRICT_MODE to CMAKE_AUTOMOC_RELAXED_MODE or something. This way the other non-standard mode would be enabled by setting a variable to TRUE instead to FALSE, which would be better IMO. Makes sense ? And I would need a better name than CMAKE_AUTOMOC_RELAXED_MODE, FORGIVING, LOOSE, better ideas ? 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 ? Better ideas ? Thanks Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding macro cmake_print_variables(var1 var2 ... varN) ?
On Sunday 11 December 2011, Alexander Neundorf wrote:
Hi,
I have a small macro/function which I need often during buildsystem
debugging:
function(PRINT_VARIABLES)
set(msg )
foreach(var ${ARGN})
if(msg)
set(msg ${msg} ; )
endif()
set(msg ${msg}${var}=\${${var}}\)
endforeach()
message(STATUS ${msg})
endfunction()
it prints the values of the variables given as arguments.
Example:
print_variables(CMAKE_C_COMPILER
CMAKE_MAJOR_VERSION
THIS_ONE_DOES_NOT_EXIST)
Gives:
-- CMAKE_C_COMPILER=/usr/bin/gcc ; CMAKE_MAJOR_VERSION=2 ;
THIS_ONE_DOES_NOT_EXIST=
Ok to add to git ?
Or should this better be
message(VARIABLES CMAKE_C_COMPILER
CMAKE_MAJOR_VERSION
THIS_ONE_DOES_NOT_EXIST)
Or not at all ?
Then I'll put it in extra-cmake-modules, but it seems to generic that I
think it makes sense to have it in cmake directly.
So, ok to add ?
Or should I wait until after 2.8.7 ?
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A few more changes to automoc before 2.8.7
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 it. Use this and that for STRICT mode compatibility. ? or for qmake compatibility ? Better ideas ? I pushed it as branch AutomocFineTuning to stage. The variable is now CMAKE_AUTOMOC_RELAXED_MODE . If that's fine with everybody, I'll merge it into next in the next days. This should still go into 2.8.7. I applied the attached patch and kdelibs build fails using the AutomocFineTuning branch (as expected). You mean setting CMAKE_AUTOMOC_RELAXED_MODE to TRUE, right ? Yes, that's expected. Uncommenting the line to invert the relaxed mode makes it build again. I'm fine with the change. However, the warnings/errors output by cmake don't include a reference to CMAKE_AUTOMOC_RELAXED_MODE (as that is not referenced in all error/warning cases). Do you have commit e474dcb23197489640456b4 already ? http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=e474dcb23197489640456b46862a5aa7019834a5 I committed this Wednesday evening and though I had inserted it in all places where it makes sense. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A few more changes to automoc before 2.8.7
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 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 ? Better ideas ? I pushed it as branch AutomocFineTuning to stage. The variable is now CMAKE_AUTOMOC_RELAXED_MODE . If that's fine with everybody, I'll merge it into next in the next days. This should still go into 2.8.7. I applied the attached patch and kdelibs build fails using the AutomocFineTuning branch (as expected). You mean setting CMAKE_AUTOMOC_RELAXED_MODE to TRUE, right ? Yes, that's expected. I mean not setting it at all and letting it take its default value of True. Do you mean the relaxed mode should be default ? Why ? In strict mode it behaves exactly as documented. For KDE it shouldn't be a problemit's just that one variable which has to be set. Uncommenting the line to invert the relaxed mode makes it build again. I'm fine with the change. However, the warnings/errors output by cmake don't include a reference to CMAKE_AUTOMOC_RELAXED_MODE (as that is not referenced in all error/warning cases). Do you have commit e474dcb23197489640456b4 already ? http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=e474dcb23197489640456b 46862a5aa7019834a5 I committed this Wednesday evening and though I had inserted it in all places where it makes sense. Yes, I have this commit already. It might make sense to put the message in the other places. I'll have a look. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] A few more changes to automoc before 2.8.7
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 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 ? Better ideas ? I pushed it as branch AutomocFineTuning to stage. The variable is now CMAKE_AUTOMOC_RELAXED_MODE . If that's fine with everybody, I'll merge it into next in the next days. This should still go into 2.8.7. I applied the attached patch and kdelibs build fails using the AutomocFineTuning branch (as expected). You mean setting CMAKE_AUTOMOC_RELAXED_MODE to TRUE, right ? Yes, that's expected. I mean not setting it at all and letting it take its default value of True. Do you mean the relaxed mode should be default ? Why ? In strict mode it behaves exactly as documented. For KDE it shouldn't be a problemit's just that one variable which has to be set. Uncommenting the line to invert the relaxed mode makes it build again. I'm fine with the change. However, the warnings/errors output by cmake don't include a reference to CMAKE_AUTOMOC_RELAXED_MODE (as that is not referenced in all error/warning cases). Do you have commit e474dcb23197489640456b4 already ? http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=e474dcb2319748964045 6b 46862a5aa7019834a5 I committed this Wednesday evening and though I had inserted it in all places where it makes sense. Yes, I have this commit already. It might make sense to put the message in the other places. I'll have a look. I had a look. From my POV they look good as they are. Where would you like to have additional mentions of CMAKE_AUTOMOC_RELAXED_MODE, and what should they actually say ? (In strict mode I don't check for all the special conditions, so it is currently not possible to reliably determine whether an error in strict mode will be handled in relaxed mode). Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] QtAutomoc dashboard failure?
On Monday 19 December 2011, David Cole wrote: Alex, Can you take a look at this and see if you know why QtAutomoc is failing on this one dashboard? http://cdash.org/CDash/testDetails.php?test=126108609build=1833949 I had a look, the output looks good: Automoc for target codeeditorLib AUTOMOC: warning: C:/Users/cjstimp/cmake_nightly/cmake/Tests/QtAutomoc/codeeditor.cpp: The file includes the moc file codeeditor.moc, but does not contain a Q_OBJECT macro. Running moc on C:/Users/cjstimp/cmake_nightly/cmake/Tests/QtAutomoc/codeeditor.h ! Better include moc_codeeditor.cpp for a robust build. This is what it should say, and this means that the included codeeditor.moc has been created, otherwise it would not have compiled. Clinton, can you please send me the Tests/QtAutomoc/ build directory zipped together ? Thanks Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] QtAutomoc dashboard failure?
On Monday 19 December 2011, Clinton Stimpson wrote: On Monday, December 19, 2011 01:59:37 pm Alexander Neundorf wrote: On Monday 19 December 2011, David Cole wrote: Alex, Can you take a look at this and see if you know why QtAutomoc is failing on this one dashboard? http://cdash.org/CDash/testDetails.php?test=126108609build=1833949 I had a look, the output looks good: Automoc for target codeeditorLib AUTOMOC: warning: C:/Users/cjstimp/cmake_nightly/cmake/Tests/QtAutomoc/codeeditor.cpp: The file includes the moc file codeeditor.moc, but does not contain a Q_OBJECT macro. Running moc on C:/Users/cjstimp/cmake_nightly/cmake/Tests/QtAutomoc/codeeditor.h ! Better include moc_codeeditor.cpp for a robust build. This is what it should say, and this means that the included codeeditor.moc has been created, otherwise it would not have compiled. Clinton, can you please send me the Tests/QtAutomoc/ build directory zipped together ? Thanks Alex I sent a .zip file. Let me know if you didn't get it. Did you see the link error? The generated codeeditor.moc is empty (0 bytes), but it shouldn't be empty. It should have been generated from codeeditor.h. I have no idea why this happens. Can you run the build with the environment variable VERBOSE set to 1 ? Then automoc will print more log messages. I also noticed it was using the wrong Qt build. It is building with Visual Studio 2005 but using a Qt built with Visual Studio 2008. I just made a change to use a compatible Qt. Maybe that helps... Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] GNUInstallDirs.cmake and Debian multiarch into next
Hi, yesterday I pushed the GNUInstallDirs-DebianMultiarch branch to stage. This has only one commit, it adds support for multiarch on Debian ti CMAKE_INSTALL_LIBDIR. I'd like to get that into 2.8.7, but I didn't want to merge it into next without having it reviewed by you. So, can you please have a look at it ? With this patch, on Debian multiarch, CMAKE_INSTALL_LIBDIR is now initialized to lib/i386-linux-gnu/ instead of simply lib, as recommended by multiarch. Thanks Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GNUInstallDirs.cmake and Debian multiarch into next
On Tuesday 20 December 2011, David Cole wrote: rc2 is tomorrow. And we've already merged in what we're going to accept for it. Unless there's something drastically wrong with rc2, I'm hoping it's the last rc before the final 2.8.7. So this one may have to wait. I merged it into next now. It's really small Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Relation between CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH
On Tuesday 03 January 2012, Eric Noulard wrote: Sorry sent too soon, finger slipped. ... I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH which seems to be reserved for cross-compiling whereas CMAKE_PREFIX_PATH CMAKE_INCLUDE_PATH CMAKE_PROGRAM_PATH CMAKE_LIBRARY_PATH CMAKE_IGNORE_PATH are meant to be used in the general case. Could someone enlighten me about the intended usage and relationship between those vars and their SYSTEM counterpart CMAKE_SYSTEM_*_PATH ? CMAKE_INCLUDE_PATH is a list of directories used by find_file() and find_path(), could include /home/mystuff/include/ CMAKE_PROGRAM_PATH is a list of directories used by find_program(), could include /home/mystuff/bin/ CMAKE_LIBRARY_PATH is a list of directories used by find_library(), could include /home/mystuff/lib/ These were added 2006 I think. Late 2007 or maybe 2008 came CMAKE_PREFIX_PATH. This make the variables above mostly unnecessary. It is a list of directories, where the respective subdirectory is appended by find_program(), find_file() etc. So for the example above you would be done by setting it to /home/mystuff/ . The directories from these variables are checked before the directories given via PATHS or HINTS. CMAKE_FIND_ROOT_PATH is different (and was added before CMAKE_PREFIX_PATH), it is a list of directories which contain root directories where the filesystem of the target system in a cross-compilation setting is location. You set it e.g. to /opt/eldk/arm/. Then cmake will prepend this root dir to each of the directories it would check otherwise. I.e. find_program() will check in /opt/eldk/arm/bin/, /opt/eldk/arm/usr/bin/, /opt/eldk/arm/usr/local/bin/, /opt/eldk/arm/usr/X11/bin/, etc. I.e. the assumption is that under those prefixes a whole normal filesystem is located. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Should a module attempt to find its own dependencies?
On Sunday 08 January 2012, Stephen Kelly wrote: 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? 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 changed by setting variables (eg, one might use QT_USE_QTXMLPATTERNS before finding Qt4). Specifically this comes up for me because I need to know whether Qt5 modules should find their own dependencies. That is, should find_package(Qt5Gui) cause find_package(Qt5Core REQUIRED) to be called or not? I'd say yes. Otherwise the imported targets in Qt5Gui will depend on not yet defined targets from Qt5Core. The same way cmake takes care of adding the required additional libraries to the link line (like adding zlib when linking libpng), it should also take care of this, IMO. You should just have to state find_package(Foo) and this will get you Foo. That implies that * Qt5Gui_INCLUDE_DIRS should also contain Qt5Core_INCLUDE_DIRS * Qt5Gui_DEFINITIONS should contain Qt5Core_DEFINITIONS * Qt5Gui_COMPILE_DEFINITIONS should contain Qt5Core_COMPILE_DEFINITIONS Right? Yes, I'd say so. But let's wait also for some opinions from others. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] RFC: standard (and not so standard) install dirs
Hi,
here comes a quite lengthy mail on issues I see in KDE but also in general
with install dirs and CMake.
in KDE we define a set of variables which hold the install destinations for
several different file types:
EXEC_INSTALL_PREFIX(${CMAKE_INSTALL_PREFIX})
SHARE_INSTALL_PREFIX (share)
BIN_INSTALL_DIR(${EXEC_INSTALL_PREFIX}/bin)
SBIN_INSTALL_DIR (${EXEC_INSTALL_PREFIX}/sbin)
LIB_INSTALL_DIR(${EXEC_INSTALL_PREFIX}/lib${LIB_SUFFIX})
LIBEXEC_INSTALL_DIR(${LIB_INSTALL_DIR}/kde4/libexec)
INCLUDE_INSTALL_DIR(include)
PLUGIN_INSTALL_DIR (${LIB_INSTALL_DIR}/kde4)
IMPORTS_INSTALL_DIR(${PLUGIN_INSTALL_DIR}/imports)
CONFIG_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/config)
DATA_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/apps)
HTML_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/doc/HTML)
ICON_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/icons)
KCFG_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/config.kcfg)
LOCALE_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/locale)
MIME_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/mimelnk)
SERVICES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/kde4/services)
SERVICETYPES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/kde4/servicetypes)
SOUND_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/sounds)
TEMPLATES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/templates)
WALLPAPER_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/wallpapers)
DEMO_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/demos)
KCONF_UPDATE_INSTALL_DIR (${DATA_INSTALL_DIR}/kconf_update)
AUTOSTART_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/autostart)
XDG_APPS_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/applications/kde4)
XDG_DIRECTORY_INSTALL_DIR(${SHARE_INSTALL_PREFIX}/desktop-directories)
XDG_MIME_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/mime/packages)
SYSCONF_INSTALL_DIR(${CMAKE_INSTALL_PREFIX}/etc)
MAN_INSTALL_DIR(${SHARE_INSTALL_PREFIX}/man)
INFO_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/info)
DBUS_INTERFACES_INSTALL_DIR(${SHARE_INSTALL_PREFIX}/dbus-1/interfaces)
DBUS_SERVICES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/dbus-1/services)
DBUS_SYSTEM_SERVICES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/dbus-1/system-
services)
As you can see, some of them are very generic, and make sense for about any
package, like LIB_INSTALL_DIR and BIN_INSTALL_DIR, some are quite KDE-
specific, like SERVICETYPES_INSTALL_DIR and KCONF_UPDATE_INSTALL_DIR, some are
related to other packages, like e.g. XDG_DIRECTORY_INSTALL_DIR and
DBUS_SERVICES_INSTALL_DIR.
These variables are defined in FindKDE4Internal.cmake, so any package doing
find_package(KDE4)
can make use of these variables for installing its stuff.
Which features/advantages does this bring:
1) all these variables can be adjusted via the cache, so users/packagers can
tweak where stuff is installed to
2) the variables which can be tweaked have standard names, so it's the same
for all KDE4-packages
3) and a special extra feature: if a project which uses kdelibs is installed
to the same CMAKE_INSTALL_PREFIX as kdelibs, all these variables are
initialized to the values from kdelibs.
E.g. if kdelibs is installed in /opt/kde, and SYSCONF_INSTALL_DIR was set to
/etc for kdelibs, for any application which does find_package(KDE4) and
where CMAKE_INSTALL_PREFIX is also set to /opt/kde, SYSCONF_INSTALL_DIR will
be set to the value from kdelibs, i.e. /etc.
So far, so good.
With the ongoing modularization of kdelibs we'd like to standardize this a bit
more and using a more generic, non KDE-specific solution.
Now since a few releases CMake has GNUInstallDirs.cmake.
This module serves a similar purpose. Unfortunately it introduced different
names for these variables, but ok.
It provides the following install destinations:
CMAKE_INSTALL_BINDIR (bin)
CMAKE_INSTALL_SBINDIR (sbin)
CMAKE_INSTALL_LIBEXECDIR (libexec)
CMAKE_INSTALL_SYSCONFDIR (etc)
CMAKE_INSTALL_SHAREDSTATEDIR (com)
CMAKE_INSTALL_LOCALSTATEDIR(var)
CMAKE_INSTALL_LIBDIR (lib or lib64)
CMAKE_INSTALL_INCLUDEDIR (include)
CMAKE_INSTALL_OLDINCLUDEDIR(/usr/include)
CMAKE_INSTALL_DATAROOTDIR (share)
CMAKE_INSTALL_DATADIR (DATAROOTDIR)
CMAKE_INSTALL_INFODIR (DATAROOTDIR/info)
CMAKE_INSTALL_LOCALEDIR(DATAROOTDIR/locale)
CMAKE_INSTALL_MANDIR (DATAROOTDIR/man)
CMAKE_INSTALL_DOCDIR (DATAROOTDIR/doc/PROJECT_NAME)
This is mostly a subset of the variables defined by KDE.
There are some additional variables (CMAKE_INSTALL_OLDINCLUDEDIR,
CMAKE_INSTALL_SHAREDSTATEDIR, CMAKE_INSTALL_LOCALSTATEDIR) which do not
Re: [cmake-developers] FindBZip2 (was: Dashboard issues with ExternalProject)
On Wednesday 11 January 2012, Rolf Eike Beer wrote:
Am Mittwoch, 11. Januar 2012, 15:32:47 schrieb Brad King:
On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
with whatever is needed to convince find_package(BZIP2) to use the
CMake-built cmbzip2 library. If you're changing the Find module for
it then what needs to be pre-loaded may depend on which version of
CMake is used to configure the build of CMake. It's a bit tricky.
I pushed an updated version to topic improve-findbzip2, hopefully that
would do it. Does this look sane?
Since you're changing the way that module looks for libraries you should
also fix up some historical wrongness in it. The Module/readme.txt file
explains that BZIP2_LIBRARIES should not be a cache variable. Instead
it should be a normal variable that collects the results from other
single-library searches. Ideally the module (with config support) should
offer these cache entries for users to set:
BZIP2_LIBRARY_RELEASE
BZIP2_LIBRARY_DEBUG
and the output should all be in a single
set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}
debug ${BZIP2_LIBRARY_DEBUG})
That's the way we currently have in next.
How about creating an imported target and use ${BZIP2_LIBRARY_RELEASE} and
${BZIP2_LIBRARY_DEBUG} to set the respective LOCATION properties ?
Like
add_library(ImportedLibrary::Bzip2 IMPORTED )
set_target_properties(ImportedLibrary::Bzip2
PROPERTIES IMPORTED_CONFIGS DEBUG;RELEASE
LOCATION_DEBUG ${BZIP2_LIBRARY_DEBUG}
LOCATION_RELEASE ${BZIP2_LIBRARY_RELEASE} )
set(BZIP2_LIBRARIES ImportedLibrary::Bzip2 )
There is a small source incompatiblity, in the case that somebody assumes
that BZIP2_LIBRARIES contains a file path, but beside that, it's a good thing
and makes stuff work better on Windows (since if another project installs an
exported targets file, and if those targets have been linked against the
installed bzip2-target, they will reference the target in their export file,
which will be found by FindBZip2.cmake at cmake-time of a using project on the
end system, instead of depending on the full fixed path to libbzip2 on the
developer system).
FindQt4.cmake does already create imported targets for the libs it finds.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: standard (and not so standard) install dirs
On Wednesday 11 January 2012, Brad King wrote: ... To support the fully flexible version, the developer must calculate the relative path from the configured CONFIG_INSTALL_DIR (where the Config.cmake file goes) to the configured INCLUDE_INSTALL_DIR. It's not too hard. See ITK for example: Depends on the definition of too ;-) I'll see whether I can come up with some macro or helper file to make it easier. http://itk.org/gitweb?p=ITK.git;a=blob;f=CMakeLists.txt;hb=v4.0.0#l558 do you have suggestions how to make the code needed in the Config.cmake files easier ? I've done this for a few projects that allow such destinations to be changed. If one destination is a full path then it can just be used as-is. If it is a relative path then I start by computing the installation prefix based on the installation depth of the Config.cmake file using get_filename_component. Then I add on the other relative destination. Yes, that's basically what I do here too: https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem/HowToInstallALibrary I don't think the case that the Config.cmake install destination is absolute and the others are relative to an installation prefix is important. I see no real-world use case to do things that way. Thanks for taking your time to read and respond to this :-) Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Support for imported targets in CMAKE_REQUIRED_LIBRARIES
Hi,
the variable CMAKE_REQUIRED_LIBRARIES is used by several of the check-modules
for listing additional libraries which should be linked.
It is common to use variables set by Find-modules for this, e.g.
set(CMAKE_REQUIRED_LIBRARIES ${JPEG_LIBRARIES} )
Now, if the module did not simply set JPEG_LIBRARIES to the full path, but
instead created an imported target, e.g. FindJPEG::libjpeg, this leads to a
problem.
The check-modules will simply append this to the linker command, so there will
be -lFindJPEG::libjpeg, which will not work.
This actually happened in KDE the first time more than 2 years ago.
On cmake stage there is now a branch HandleTargetsInCMakeRequiredLibraries,
where I ported the solution from KDE to CMake and applied it to all places
where CMAKE_REQUIRED_LIBRARIES is used.
I did not test it yet (but it should work, since it is exactly the same as in
KDE).
Please have a look at it.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] FindPackageHandleStandardArgs: fix documentation
On Friday 20 January 2012, Brad King wrote: On 1/20/2012 8:57 AM, Yury G. Kudryashov wrote: Brad King wrote: I do not think that explanation is correct. The find_package command in Config mode will set everything as needed. Yes, so the old explanation is incorrect. The role of the CONFIG_MODE option is to produce a nice error message when the package is not found. I've searched FPHSA.cmake for CONFIG_MODE, and found the following code snippets: Sorry, I misread the new wording originally. I applied it and tweaked the wording a bit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26015bab Fine with me. I'm not sure I see why the modified version is better than before, but it's ok. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Support for imported targets in CMAKE_REQUIRED_LIBRARIES
On Friday 20 January 2012, Brad King wrote:
On 1/19/2012 11:49 AM, Alexander Neundorf wrote:
On Thursday 19 January 2012, Brad King wrote:
I think a full solution to this will end up duplicating a lot of the
logic that CMake already has in its C++ code for link dependency
analysis. I wonder if instead you could modify the signature of
try_compile to accept the LINK_LIBRARIES as a formal argument. Then
teach the C++ code to resolve the imported targets and take care of the
link interfaces.
I'll have a look at that too.
What things exactly do you have in mind additionally ?
Rather than jumping to an implementation of my proposal let's think through
the interface. The src-file signature of try_compile is currently:
try_compile(RESULT_VAR bindir srcfile
[CMAKE_FLAGS flags...]
[COMPILE_DEFINITIONS flags...]
[OUTPUT_VARIABLE var]
[COPY_FILE fileName])
The CMakeLists.txt it generates includes the line
TARGET_LINK_LIBRARIES(cmTryCompileExec ${LINK_LIBRARIES})
so right now one uses the CMAKE_FLAGS option to pass -DLINK_LIBRARIES=...
to specify link libraries. The try_compile command has no chance to
recognize which options are libraries. Instead, let's add a LINK_LIBRARIES
option to try_compile:
try_compile(RESULT_VAR bindir srcfile
... [LINK_LIBRARIES libs...] ...)
Then the implementation of the command can evaluate the libs... arguments
in a context where imported targets are known. Loop over each library.
For those that this-Makefile-FindTargetToUse() returns a target, verify
that it is IMPORTED, and then call target-GetLinkInformation(config),
where config is the try-compile's configuration. The return value of
that will be a cmComputeLinkInformation object from which you can query
the link line.
I'm getting there.
To get the link line I moved code from cmLocalGenerator::OutputLinkLibraries()
into a separate function GetLinkLine(cmTarget, cmComputeLinkInformation).
But before I get there I get a segfault:
#0 0x0821f1d7 in std::vectorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar , std::allocatorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar ::begin() const ()
#1 0x0827f733 in cmTarget::ComputeLinkClosure(char const*,
cmTarget::LinkClosure) ()
#2 0x0827f594 in cmTarget::GetLinkClosure(char const*) ()
#3 0x0827f44a in cmTarget::GetLinkerLanguage(char const*) ()
#4 0x0832a29a in
cmComputeLinkInformation::cmComputeLinkInformation(cmTarget*, char const*) ()
#5 0x08286f1b in cmTarget::GetLinkInformation(char const*) ()
#6 0x082bf5ab in cmCoreTryCompile::CreateProject(std::basic_stringchar,
std::char_traitschar
Still figuring out what's going wrong there...
It crashes in cmTarget::ComputeLinkClosure() because
mTarget::GetLinkImplementation() returns 0 for imported targets. It probably
should not get there at all, since calling GetLinkerLanguage() always leads to
that path.
Well, enough for today...
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving CPack Documentation (and may be others as well)
On Wednesday 25 January 2012, Eric Noulard wrote: 2012/1/25 Brad King brad.k...@kitware.com: On 1/24/2012 5:50 PM, Eric Noulard wrote: cmake --help-module CPackComponent or any other (untouched module) cmake --help-module FindQt4 you'll see that the extra space are there as well. So yes there is too much space, but this is not due to my current proposal, it was there before. We can handle that separately. Agreed. Sorry, I forgot that this problem already existed. It was created by the original module documentation extractor. It inconsistently treats transitions from paragraph text to preformatted text and back, giving the latter extra blank lines. Now we can't fix it without changing the formatting of all the existing documentation. (Perhaps the markup can help with that later.) I won't be doing this now I'd rather agree on the new markup feature first. The markup feature looks fine to me. The markup syntax adds some information even for those reading the raw source. Yes and I forgot to mention that it has a extra feature compared to the current module doc parser. It does look for markup on the **whole** file unlike current module doc parser which only parse the header (at the beginning of the file). So with my proposal you can perfectly document a script in the middle of the file or as usual just in front of the concerned macro/function/var. This may be easier for doc maintenance because the function/macro would be closer to its doc. This could be further used for user script that could be documented this way as well. My idea for user script doc support may be to add an extra cdoc command that would be dedicated to documentation of script files: a) cdoc --help-command-list yourscript.cmake b) cdoc --help-variable-list yourscript.cmake c) cdoc --help yourscript.cmake may spit out: a) the doc for macro/function in the concerned script b) the doc for variables c) all doc this command may have more versatile option to include or exclude (cmake/ctest/cpack) doc and/or add some path where to parse all *.cmake files etc An alternative would be to defined something like: CMAKE_USER_DOC_PATHS CPACK_USER_DOC_PATHS CTEST_USER_DOC_PATHS cmake already supports CMAKE_MODULE_PATH for generating help, e.g. like this: $ cmake -DCMAKE_MODULE_PATH=$HOME/src/kdelibs/cmake/modules/ --help-custom- modules This generates docs for all cmake files in CMAKE_MODULE_PATH. --help-module also looks in CMAKE_MODULE_PATH. I'm not sure it needs a new variable. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Topic branches in limbo on the stage?
On Wednesday 08 February 2012, David Cole wrote: The stage is intended only for topics that are imminently going to be merged to 'next'... The following CMake topic branches have been on the stage for quite some time without being merged to 'next': UseEnabledLanguagesForDirectoryInformationFileIncludePath | master=0 next=0 I forgot to delete that one, done. qt4-deploy | master=0 next=0 HandleTargetsInCMakeRequiredLibraries | master=0 next=0 I will continue to work on this one in the next days. CPackNSIS-fixIgnore-INCLUDE_TOPLEVEL | master=0 next=0 qt4-deploy-test | master=0 next=0 findblas-bugs | master=0 next=0 Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindImageMagick.cmake backwards compatibility
On Monday 30 January 2012, David Cole wrote: ... From your original post: So when ImageMagick is installed everything behaves as always. But if no ImageMagick is installed behaviour was this: find_package(ImageMagick) - ImageMagick_FOUND = TRUE This is simply clearly incorrect, and is one of those changes that deserves to have its backwards compatibility broken. If I were a client of this module, and I had logic that really depended on ImageMagick being found, then it would be broken already in some other way anyhow. I would rather have ImageMagick_FOUND be set correctly than have it be set incorrectly but the same as the last version of CMake. Same for me. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
On Monday 13 February 2012, Brad King wrote:
On 2/13/2012 4:52 PM, Alexander Neundorf wrote:
we are hoping that more and more libraries will install Config.cmake
files (and for kdelibs this is actually happening right now), so we
should make sure it is straighforward to create proper Config.cmake
files.
This is a worthwhile goal, but I do not like the approach proposed:
(1) It makes BarConfig.cmake depend on a file not distributed with it.
Well, CMakeConfigHelpers.cmake would be shipped with cmake, so as long as the
Config.cmake file says
cmake_minimum_required(VERSION 2.8.8)
it would be fine.
(2) The content of a relocatable BarConfig.cmake should not depend on where
it happened to be installed when the package was built.
I don't see a real problem with this.
Actually it is a good thing if the Config.cmake file can detect whether it is
in the location where it should be according to CMAKE_INSTALL_PREFIX, e.g. to
ensure that the libraries are installed in the right location (so the builtin
RPATHs point to the right location).
I'd rather see an approach that processes paths during configuration
of the original package. Provide some helper macros that can configure
BarConfig.cmake with the proper code in it to compute paths relative
to its location:
include(CMakePackageConfigHelper)
cmake_package_config_for_install(Bar
DESTINATION lib/cmake/Bar # install destination
# INPUT BarConfig-install.cmake.in # alternate input
)
This would look for BarConfig.cmake.in (or whatever INPUT says) and
do configure_file along with install(FILES). The module can document
some standard @CONFIG@ variables that can be used inside the input
file to get various paths:
$ cat BarConfig.cmake.in
@PACKAGE_INIT@
set(BAR_INCLUDE_DIRS @PACKAGE_PREFIX@/include/bar)
...
The @PACKAGE_INIT@ would be replaced by code to compute the install
prefix using knowledge the of the install DESTINATION of the config
file and store it in an unspecified variable (say Bar_PREFIX) that
is referenced by @PACKAGE_PREFIX@, which is replaced by ${Bar_PREFIX}.
How would that work if INCLUDE_INSTALL_DIR is an absolute path ?
set(BAR_INCLUDE_DIRS @INCLUDE_INSTALL_DIR@)
Would the case that DATA_INSTALL_DIR and LIB_INSTALL_DIR point to completely
different locations be handled ?
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
Brad King wrote:
On 2/13/2012 4:52 PM, Alexander Neundorf wrote:
we are hoping that more and more libraries will install Config.cmake
files (and for kdelibs this is actually happening right now), so we
should make sure it is straighforward to create proper Config.cmake
files.
This is a worthwhile goal, but I do not like the approach proposed:
(1) It makes BarConfig.cmake depend on a file not distributed with it.
(2) The content of a relocatable BarConfig.cmake should not depend on
where it happened to be installed when the package was built.
I'd rather see an approach that processes paths during configuration
of the original package. Provide some helper macros that can configure
BarConfig.cmake with the proper code in it to compute paths relative
to its location:
include(CMakePackageConfigHelper)
cmake_package_config_for_install(Bar
DESTINATION lib/cmake/Bar # install destination
# INPUT BarConfig-install.cmake.in # alternate input
)
This would look for BarConfig.cmake.in (or whatever INPUT says) and
do configure_file along with install(FILES). The module can document
some standard @CONFIG@ variables that can be used inside the input
file to get various paths:
$ cat BarConfig.cmake.in
@PACKAGE_INIT@
set(BAR_INCLUDE_DIRS @PACKAGE_PREFIX@/include/bar)
Another way to achieve the same result:
set(INCLUDE_INSTALL_DIR include) # relative
set(MYPKGDATA_INSTALL_DIR ${CMAKE_PREFIX_PATH}/share/mypkg) # absolute
cmake_package_config_for_install(Bar
DESTINATION lib/cmake/Bar
INPUT BarConfig-install.cmake.in
PATH_VARS
INCLUDE_INSTALL_DIR # interpreted as relative to install prefix
MYPKGDATA_INSTALL_DIR # absolute
)
will substitute @PACKAGE_INCLUDE_INSTALL_DIR@ by ../../../include and
@PACKAGE_MYPKGDATA_INSTALL_DIR@ by ../../../share/mypkg (both transformed
to be relative to DESTINATION).
A problem I see here (and which we discussed already before on kde-
buildsystem) is the handling of the install() command.
The targets file and the version file have to be installed to the same
directory.
Currently I would do it like this:
configure_file(BarConfig.cmake.in BarConfig.cmake)
write_basic_config_version_file(BarConfigVersion.cmake
VERSION ${BAR_VERSION}
COMPATIBILITY AnyNewerVersion )
install(EXPORT BarExport DESTINATION ${CMAKECONFIG_INSTALL_DIR}
FILE BarTargets.cmake )
install(FILES BarConfig.cmake
BarConfigVersion.cmake
DESTINATION ${CMAKECONFIG_INSTALL_DIR} )
With the macro as suggested above, it would become:
write_basic_config_version_file(BarConfigVersion.cmake
VERSION ${BAR_VERSION}
COMPATIBILITY AnyNewerVersion )
cmake_package_config_for_install(Bar
DESTINATION ${CMAKECONFIG_INSTALL_DIR}
INPUT BarConfig.cmake.in
PATH_VARS INCLUDE_INSTALL_DIR DATA_INSTALL_DIR)
install(EXPORT BarExport DESTINATION ${CMAKECONFIG_INSTALL_DIR}
FILE BarTargets.cmake )
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/BarConfigVersion.cmake
DESTINATION ${CMAKECONFIG_INSTALL_DIR} )
What I don't like about this is that the three files which go into the same
directory are installed in three separate commands (install(FILES),
install(EXPORTS), cmake_package_config_for_install() ).
I thought a bit about a syntax like this, which I would like:
configure_config_file(BarConfig.cmake.in BarConfig.cmake
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
PATH_VARS INCLUDE_INSTALL_DIR DATA_INSTALL_DIR
EXPORT_FILE BarExport.cmake)
write_basic_config_version_file(${CMAKE_CURRENT_BINARY_DIR}/BarConfigVersion.cmake
VERSION ${BAR_VERSION}
COMPATIBILITY AnyNewerVersion )
install(EXPORT BarExport DESTINATION ${CMAKECONFIG_INSTALL_DIR}
FILE BarTargets.cmake )
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/BarConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/BarConfigVersion.cmake
DESTINATION ${CMAKECONFIG_INSTALL_DIR} )
but this can't work, can it ?
In the BarConfig.cmake file there would still be either a
set(BAR_INCLUDE_DIR @INCLUDE_INSTALL_DIR@)
which would work for absolute paths, or a
set(BAR_INCLUDE_DIR ${SomePrefix}/@INCLUDE_INSTALL_DIR@)
which would work only for relative paths, but a simple set() cannot work for
both cases. Am I missing something ?
So I think there has to be a special macro to be used for setting those
variables in the Config.cmake file, which takes care of converting a relative
path into an absolute, and of potentially relocating an absolute path.
Do you have a working example ?
This week Thursday and Friday I'll have
Re: [cmake-developers] Making Config.cmake files easier to write
On Tuesday 14 February 2012, Brad King wrote: On 2/14/2012 1:26 PM, Alexander Neundorf wrote: Well, CMakeConfigHelpers.cmake would be shipped with cmake, so as long as the Config.cmake file says cmake_minimum_required(VERSION 2.8.8) it would be fine. ...and we have to maintain compatibility in the module no matter what. It is much easier if the config files are standalone. Yes, that's a good point. Another option would be to install the included file along the Config.cmake file. (2) The content of a relocatable BarConfig.cmake should not depend on where it happened to be installed when the package was built. I don't see a real problem with this. Actually it is a good thing if the Config.cmake file can detect whether it is in the location where it should be according to CMAKE_INSTALL_PREFIX, e.g. to ensure that the libraries are installed in the right location (so the builtin RPATHs point to the right location). Leaving remnants of the original build/install location is a no-no for packagers. I don't know, we could ask them. Actually I don't think it would be a problem for a Linux distro packager, since in this case the original install destination will be also the final actual install location. I mean, they build the package for a place where it should be installed, and if you install the package via the normal package managers, this is where they will end up. Also, this wouldn't leave anything of the original build location in the file, only the intended install location. And this is what we do anyway since kdelibs 4.0. Right now we have code like this in KDE's installed files: ... if (NOT KDE4_INSTALL_DIR) set(KDE4_INSTALL_DIR /home/alex/installs/kdelibs) endif (NOT KDE4_INSTALL_DIR) set(KDE4_LIB_INSTALL_DIR /home/alex/installs/kdelibs/lib) set(KDE4_LIBEXEC_INSTALL_DIR /home/alex/installs/kdelibs/lib/kde4/libexec) set(KDE4_INCLUDE_INSTALL_DIR /home/alex/installs/kdelibs/include) ... and no packager ever complained that this would be a problem. How would that work if INCLUDE_INSTALL_DIR is an absolute path ? set(BAR_INCLUDE_DIRS @INCLUDE_INSTALL_DIR@) Would the case that DATA_INSTALL_DIR and LIB_INSTALL_DIR point to completely different locations be handled ? See my discussion with Yuri in this thread. I saw and replied, and can't really understand how I should write the BarConfig.cmake.in to make it work. Alternatively, Yuri suggested this in a thread on kde-buildsystem, there could be a macro which completely generates the Config.cmake file. This would get rid of a bunch of problems, like having to write complicated code in the Config.cmake file, but OTOH it would have to take quite a lot of parameters, e.g. how it should set up the LIBRARY variables from the exported targets, in which namespace they have been exported, etc. This would be a quite big macro. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
On Tuesday 14 February 2012, Alexander Neundorf wrote:
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
will substitute @PACKAGE_INCLUDE_INSTALL_DIR@ by ../../../include
and @PACKAGE_MYPKGDATA_INSTALL_DIR@ by ../../../share/mypkg (both
transformed to be relative to DESTINATION).
A problem I see here (and which we discussed already before on kde-
buildsystem) is the handling of the install() command.
I thought a bit about a syntax like this, which I would like:
configure_config_file(BarConfig.cmake.in BarConfig.cmake
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
PATH_VARS INCLUDE_INSTALL_DIR DATA_INSTALL_DIR
EXPORT_FILE BarExport.cmake)
Why do you need EXPORT_FILE parameter? How can you use it? Include
automatically? Then you need VERSION_FILE parameter as well.
but this can't work, can it ?
In the BarConfig.cmake file there would still be either a
set(BAR_INCLUDE_DIR @INCLUDE_INSTALL_DIR@)
which would work for absolute paths, or a
set(BAR_INCLUDE_DIR ${SomePrefix}/@INCLUDE_INSTALL_DIR@)
which would work only for relative paths, but a simple set() cannot
work for both cases. Am I missing something ?
You'll have in BarConfig.cmake.in
set(BAR_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@)
After configure_config_file() you'll have
# At top
get_filename_component(_PKG_CURRENT_DIR ${CURRENT_LIST_FILE} PATH)
Just a tip: since 2.8.3 or so there is ${CMAKE_CURRENT_LIST_DIR}
get_filename_component(_PKG_PREFIX_PATH ${_PKG_CURRENT_DIR}/../../..
ABSOLUTE)
The ../../../ will be also calculated by the macro, using RELATIVE_PATH and
the DESTINATION parameter, right ?
#in place of your set()
set(BAR_INCLUDE_DIR ${_PKG_PREFIX_PATH}/include)
Do you have a working example ?
Not yet. I think about something like this (not tested).
foreach(var ${PACAKGE_HELPER_PATH_VARS})
if(NOT DEFINED ${var})
message(FATAL_ERROR ...)
else if(IS_ABSOLUTE ${${var}})
file(RELATIVE_PATH PACKAGE_HELPER_${var} ${CMAKE_INSTALL_PREFIX}
${${var}})
else()
set(PACKAGE_HELPER_${var} ${${var}})
endif()
endforeach()
It would be nice to make those PACKAGE_HELPER_* vars local to
configure_config_file() function.
If it's a function(), they are local automatically.
Also still not tested, but now it should have the right prefix:
foreach(var ${PACAKGE_HELPER_PATH_VARS})
if(NOT DEFINED ${var})
message(FATAL_ERROR ...)
else if(IS_ABSOLUTE ${${var}})
string(REPLACE ${CMAKE_INSTALL_PREFIX} \${_PKG_PREFIX_PATH}
PACKAGE_HELPER_${var} ${${var}}
else()
set(PACKAGE_HELPER_${var} ${${var}})
endif()
else()
set(PACKAGE_HELPER_${var} \${_PKG_PREFIX_PATH}/${${var}})
endif()
endforeach()
Ok, a working ConfigureConfigFile.cmake is attached, together with example
files, input and the configured output and the driving CMakeLists.txt.
The call now looks like this:
configure_config_file(BarConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/BarConfig.cmake
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
PATH_VARS INCLUDE_INSTALL_DIR
BIN_INSTALL_DIR
FOO_INSTALL_DIR ...
)
and in the Config.cmake.in file you have to put:
@CONFIG_HELPER_DIRS_INIT@
set_and_check(BAR_INCLUDE_DIR @CONFIG_HELPER_INCLUDE_INSTALL_DIR@)
set(BAR_DATA_DIR@CONFIG_HELPER_DATA_INSTALL_DIR@)
The set_and_check() macro is provided by the @CONFIG_HELPER_DIRS_INIT@, it
sets the variable and checks that the given directory or file exists.
IMO it's a bit much macro magic.
I'll also try an alternative approach tomorrow.
Comments ?
Alex
# set the version of myself
set(BAR_VERSION_MAJOR @BAR_VERSION_MAJOR@)
set(BAR_VERSION_MINOR @BAR_VERSION_MINOR@)
set(BAR_VERSION_PATCH @BAR_VERSION_PATCH@)
set(BAR_VERSION ${BAR_VERSION_MAJOR}.${BAR_VERSION_MINOR}.${BAR_VERSION_PATCH} )
# get_filename_component(CONFIG_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/@CONFIG_RELATIVE_PATH@ ABSOLUTE)
@CONFIG_HELPER_DIRS_INIT@
set_and_check(BAR_INCLUDE_DIR @CONFIG_HELPER_INCLUDE_INSTALL_DIR@)
set_and_check(BAR_BIN_DIR @CONFIG_HELPER_BIN_INSTALL_DIR@)
set(BAR_DATA_DIR@CONFIG_HELPER_DATA_INSTALL_DIR@)
set(BAR_BAR_DIR @CONFIG_HELPER_BAR_INSTALL_DIR@)
set(BAR_FOO_DIR @CONFIG_HELPER_FOO_INSTALL_DIR@)
# what is my include directory
set(BAR_INCLUDES ${BAR_INCLUDE_DIR})
# import the exported targets
include(${CMAKE_CURRENT_LIST_DIR}/BarTargets.cmake)
# set the expected library variable
set(BAR_LIBRARIES bar )
cmake_minimum_required(VERSION 2.8.7)
project(Bar)
# the version number, needed for
# - the library version
# - version detection
[cmake-developers] Bad error message when a package could not be found - make find_package() not search config files by default
Hi, when I use a Find-module to search for a package, I get a nice error message if the package could not be found. If I use find_package(Foo) and rely on Config-mode, cmake produces an error message which doesn't help the user: ~/src/extra-cmake-modules/example/b$ make rebuild_cache Running CMake to regenerate build system... CMake Error at CMakeLists.txt:4 (find_package): Could not find module Findextra-cmake-modules.cmake or a configuration file for package extra-cmake-modules. Adjust CMAKE_MODULE_PATH to find Findextra-cmake-modules.cmake or set extra-cmake-modules_DIR to the directory containing a CMake configuration file for extra-cmake-modules. The file will have one of the following names: extra-cmake-modulesConfig.cmake extra-cmake-modules-config.cmake -- modules path: -- CMake Error at CMakeLists.txt:13 (ecm_use_find_modules): Unknown CMake command ecm_use_find_modules. -- Configuring incomplete, errors occurred! make: *** [rebuild_cache] Error 1 I see several issues here, sorted by importance: 1) the user doesn't know whether his build was supposed to use a Find-module or whether it was supposed to find the Config.cmake file. Especially since there is no file present which tells him that. With Find-modules he can have a look at the Find-module and he will see which header or library cmake is looking for. In the case of a missing Config.cmake file this is not possible. This is IMO a major problem. The user has no chance to guess which file he should look for, and where it should come from: FindFoo.cmake, FooConfig.cmake or Foo-config.cmake. 2) the first thing the error message recommends is to adjust CMAKE_MODULE_PATH. But probably either Foo is not installed at all, or the user should adjust CMAKE_PREFIX_PATH so Foo can be found. But CMAKE_PREFIX_PATH is not mentioned at all. 3) cmake continues processing the CMakeLists.txt even after the REQUIRED message could not be found. IMO it should fail with FATAL_ERROR. What to do about it ? 3) should be easy to solve by failing differently. I can do that. 1) and 2): What I usually recommend is to use a tiny FindFoo.cmake file which basically contains find_package(FOO NO_MODULE). This way the user can find information what went wrong. But it doesn't seem like everybody is doing this. So it should be enforced or at least always obvious what cmake is searching. So here is my proposal: make find_package() search only for Find-modules by default, and only search for config.cmake files if NO_MODULE was used (maybe add a positive option CONFIG_MODE). If then a config.cmake file was not found, the error message can say definitely whether a Find-module was not found, and CMAKE_MODULE_PATH is wrong, or whether the Config.cmake file was not found, and CMAKE_PREFIX_PATH should be adjusted. Also, by looking at the CMakeLists.txt, the user can see whether a Find-module or a Config.cmake file should be found. I am aware that this is quite a change, but thanks to the policy system it shouldn't be able to break anything. I consider this necessary, to avoid the feeling of helplessness among users because they have no idea what went wrong in cmake's configure step. Comments, objections ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Support for imported targets in CMAKE_REQUIRED_LIBRARIES
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 6:32 AM, Alexander Neundorf wrote:
Done, and pushed to stage.
I added the prefix cmake_ to the function, and added a test for it.
Looks good, thanks.
However now that I look at the end result I realize that the functionality
is not specific to CMAKE_REQUIRED_LIBRARIES at all. It is a general
conversion from imported targets to raw file paths. Perhaps the name
and interface could be made more general:
include(CMakeExpandImportedTargets)
cmake_expand_imported_targets(result LIBRARIES
${CMAKE_REQUIRED_LIBRARIES})
I can change that if you want it.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bad error message when a package could not be found - make find_package() not search config files by default
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 8:19 AM, Alexander Neundorf wrote:
Comments, objections ?
The entire point of find_package's interface is that the caller
does not need to care how the package is found, and the actual
method used for the find can change under the hood.
Ideally every package would provide a package config file in its
installation and we would never need Find modules. In that case
having the extra keyword in every find_package call would be ugly.
I don't think I agree with this.
It should be easily visible what find_package() is looking for, otherwise you
are completely lost what is missing if find_package() did not find the
package.
If you don't like the error message then you are free to write
find_package(Foo NO_MODULE)
anywhere you want.
I personally do that usually, because I know quite well how it works.
The average developer doesn't do this, because for him it works, he usually
has the package installed, and if it is not found, he knows why, because he is
working on it.
I think it should really be enforced to make explicit if a Config-file is
searched.
People have got used to Find-modules, and now those new Config.cmake files
start to appear, which many developers don't know anything about.
Even more so non-developers which just want to build a package.
If I would try to build some downloaded package which does
find_package(Foo 1.0.0)
and cmake tells me that it couldn't find a FindFoo.cmake and also no
FooConfig.cmake and no Foo-config.cmake, I would basically give up at this
moment. Maybe the developer had wrong assumption when building on his machine,
maybe he had some weird installation where some project had installed a
FindFoo.cmake into a directory searched by cmake, if CMAKE_MODULE_PATH is set
up e.g. from an environment variable:
set(CMAKE_MODULE_PATH $ENV{MY_CMAKE_MODULE_DIR} )
or something.
This is not too far fetched, there are emails from time to time how to set up
such a directory so that Find-modules can be shared.
Let's make cmake more strict, to avoid confusion and to make clearer what is
going on.
Perhaps you can add an alternative keyword so
that this can be written
find_package(Foo CONFIG)
instead for those authors who want to do so. Furthermore if you
want to guarantee that a Find module is used then add a mode like
find_package(Foo MODULE)
so that the command knows that it is an error if FindFoo does not
exist in CMAKE_MODULE_PATH.
In any of the above modes the error message can be more explicit.
It is up to the author of the project to choose to do this. I do
not want it to be required.
Here we disagree. I think it should be required, to avoid the impression
finding packages with cmake is a total mess among users who don't know the
details of cmake package searching.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
On Thursday 16 February 2012, Brad King wrote: On 2/16/2012 10:15 AM, Alexander Neundorf wrote: On Thursday 16 February 2012, Brad King wrote: In hindsight that name was poorly chosen. I'd really like to see package in the name because they are package configuration files. Otherwise there is no indication it has anything to do with find_package. Well, it has to do with Config files :-) Okay, so it can have PackageConfig in its name since they are package configuration files. So which one ? 1) configure_config_file() + write_basic_config_version_file() 2) configure_package_file() + write_basic_config_version_file() 3) configure_package_file() + write_basic_package_version_file() Personally, I prefer 1) and 3) over 2). include(CMakePackageConfigHelper) # CMakeConfigHelper is ambiguous IMO configure_package_config_file(...) write_basic_config_version_file(...) # no need to change name Ok, so we have 1) configure_config_file() + write_basic_config_version_file() 2) configure_package_file()+ write_basic_config_version_file() 3) configure_package_file()+ write_basic_package_version_file() 4) configure_package_config_file() + write_basic_config_version_file() 5) configure_package_config_file() + write_basic_package_version_file() 6) configure_package_config_file() + write_basic_package_config_version_file() My choice would be: 1), 5), 6), 3), 4), 2) So, 5) ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
