Re: [cmake-developers] framework-interface-includes topic
Brad King wrote: Steve, Thanks for working on this. Please update the documentation of tll() to mention this behavior. Also, the use of CollapseFullPath to evaluate /.. seems more complicated than necessary. A single CollapseFullPath of the original input followed by a check against a pre-compiled regex can check for framework paths in one step. What would such a regex look like? Thanks, Steve. -- 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] compile-defs-debugging and framework-interface-includes
Hi there, compile-defs-debugging is failing with some Visual Studio generators. I don't have those ides to figure out what is going wrong. My reading of the Preprocessor test indicates that if my new test fails, that one should too, so I don't understand where the problem is. The framework-interface-includes test is also failing on all macs, after I changed it to use a regex to match a framework. I don't have ready access to a mac for a few days to find out what is wrong there. Can I get some help with those issues? Thanks, Steve. -- 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] compile-defs-debugging and framework-interface-includes
clin...@elemtech.com wrote: The framework-interface-includes test is also failing on all macs, after I changed it to use a regex to match a framework. I don't have ready access to a mac for a few days to find out what is wrong there. I've pushed a fix for you on stage/framework-interface-includes. Awesome, thanks. I've squashed it into the original. Thanks, Steve. -- 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] Please review CXXFeatures.cmake
Rolf Eike Beer wrote: Ok, I've pushed an updated version to the rework branch. A test for the component check is missing, but all of your other suggestions should have been addressed. Has anyone anything else, otherwise I will o and put this into CMake next once I have the test. Do you have any response to the issue from Thiago here? http://thread.gmane.org/gmane.comp.kde.devel.core/80156/focus=80172 The header generated by your module would have to be installed, right? Otherwise it would make more sense to just use 'override' directly. The generated header is specific to whatever compiler was used when cmake generated it. Thanks, Steve. -- 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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote: Hi Stephen, Did you have any chance to look at the code? I would love to see it integrated in the next release. That being said, there is no pressure. I'll have a look now. +UpdateOutputToSourceMap(outputs, file); is missing a 'this-', as per the style. There's a couple of repeats of that. Please rename typedef std::mapstd::string, cmSourceFile* OutputToInputMap; to OutputToSourceMap for similarity to the OutputToSource variable. I haven't tried it out yet, but it looks sane to me. The UpdateOutputToSourceMap could probably be faster if outputs is sorted and you use lower-bound insertion in a loop over the map or so. If it's fast enough already though, probably no need for that :). I'd say the topic can be cleaned up and force pushed for another review. Thanks, Steve. -- 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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote:
+UpdateOutputToSourceMap(outputs, file);
is missing a 'this-', as per the style. There's a couple of repeats of
that.
Done
You seem to have missed this one.
There are also other style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
That's said we can optimize further as I mentioned in my comment (
https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023).
Do you have an opinion about it?
Do I understand correctly that the issue is that OutputToSource values can
be absolute or relative paths? That would be fixable by patching only
UpdateOutputToSourceMap, right?
Thanks,
Steve.
--
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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote: That's said we can optimize further as I mentioned in my comment ( https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023 ). Do you have an opinion about it? Do I understand correctly that the issue is that OutputToSource values can be absolute or relative paths? That would be fixable by patching only UpdateOutputToSourceMap, right? Not exactly. According to my tests only cmMakefiles::GetSourceFileWithOutput's cname argument can be either relative or absolute. Then patching the callers of GetSourceFileWithOutput is worth looking into. There are not many. You'd have to try it and see if any issues come up. Thanks, Steve. -- 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] CPack BAR package generator
Hi there, I've pushed a cpack-bar-package topic to my clone https://gitorious.org/~steveire/cmake/steveires-cmake It is the start of a CPack generator for BlackBerry BAR packages, required for deployment to those devices. I haven't worked much with CPack before, so I'd appreciate some feedback even at this early point. Some issues that have come up already are in the commit message. Thanks, Steve. -- 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] target_link_libraries, IMPORTED targets and SYSTEM includes
Hi,
In response to
https://bugreports.qt-project.org/browse/QTBUG-32599
I first considered adding something like
if(NOT QT_INCLUDE_DIRS_NO_SYSTEM)
set_property(TARGET Qt5::Core
SYSTEM_INTERFACE_INCLUDE_DIRECTORIES
${Qt5Core_INCLUDE_DIRS}
)
endif()
for each imported target, which would cause CMake to treat the includes for
it as system includes.
Then I had the idea that I didn't like the API of
set(QT_INCLUDE_DIRS_NO_SYSTEM 1)
find_package(Qt5Core)
and I prefered
find_package(Qt5Core)
add_library(foo ...)
target_link_libraries(foo SYSTEM Qt5::Core)
which has a similar effect as the SYSTEM keyword in
target_include_directories.
I implemented that without a test so far in tll-system-includes-signature in
my clone. However, the motivation for that is that I generally want to treat
all 'external' headers as system includes, and Qt is just a common external
dependency.
Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED targets as
SYSTEM includes automatically?
Thanks,
Steve.
--
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] Shared library names with numerical suffix
Hi,
Commit 342fc0401005 (Recognize shared library files with a numerical suffix,
2013-04-11) resulted from
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6613/focus=6616
In a more-recent review, I thought that if there is an extension in the exts
list which already has a numerical extension, then the extra check for a
numerical extension shouldn't be added for that entry.
else if(type == LinkShared)
{
libext += (\\.[0-9]+)?;
}
The code is quite complex with regexes. I wonder if something like that can
be fixed, or should it just be left as-is?
Thanks,
Steve.
--
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_link_libraries, IMPORTED targets and SYSTEM includes
Brad King wrote: On 07/25/2013 09:16 AM, Stephen Kelly wrote: target_link_libraries(foo SYSTEM Qt5::Core) That looks okay to me so long as SYSTEM must always be the first keyword. Yes, that's how I've implemented it currently. We could also consider adding it only to the modern (newest) keyword signature to encourage conversion to it. I considered that, but I think the plain signature without INTERFACE_LINK_LIBRARIES is going to remain most common in executable lhs cases. I didn't see any need to exclude it from only the signature with INTERFACE_LINK_LIBRARIES. Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED targets as SYSTEM includes automatically? I don't think so because one could be importing targets from a dependency that was just built as part of a superbuild and may want to see the warnings. I considered that, but if you're building it as part of a superbuild, you'll still get the warning when building the dependency itself. You control the flags used to build the dependency, so you can add the flag to trigger the warning when building the dependency. If the dependency is something you bundle, like zlib as in the case of Qt and cmake, then you don't want to maintain patches to clean the headers, but you want them upstream. At the same time, you don't want to trigger the warnings which may be new with your compiler (usused typedefs is a common one nowadays) when using the bundled dependency. When building it, you disable that warning, and when using it, you want its headers treated as system headers, but you still want the unused typedef warning for your own code. So, I think it still makes sense to treat all interface include directories of IMPORTED targets as SYSTEM includes. Thanks, Steve. -- 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_link_libraries, IMPORTED targets and SYSTEM includes
Matthew Woehlke wrote: On 2013-07-25 11:25, Stephen Kelly wrote: Brad King wrote: On 07/25/2013 09:16 AM, Stephen Kelly wrote: Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED targets as SYSTEM includes automatically? I don't think so because one could be importing targets from a dependency that was just built as part of a superbuild and may want to see the warnings. I considered that, but if you're building it as part of a superbuild, you'll still get the warning when building the dependency itself. Not necessarily; library A may provide a utility header that it doesn't actually use internally, and library B may use it and produce a warning. Edge case. Even then, library A should have a unit test which attempts to compile all of its headers with all warnings enabled. In Qt every module has a 'headersclean' unit test which does exactly that. https://qt.gitorious.org/qt/qtbase/blobs/dev/mkspecs/features/qt_headersclean.prf (Besides there is more chance of noticing a warning the more times it trips. For that matter, wouldn't this defeat the purpose in the original post of being able to include Qt as non-SYSTEM?) The purpose in the bug report is not to include Qt as non-SYSTEM, but the opposite. I don't see any reason for downstreams to include Qt headers as non-SYSTEM headers. Thanks, Steve. -- 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_link_libraries, IMPORTED targets and SYSTEM includes
Matthew Woehlke wrote: On 2013-07-25 13:25, Stephen Kelly wrote: Brad King wrote: On 07/25/2013 12:22 PM, Stephen Kelly wrote: library A should have a unit test which attempts to compile all of its headers with all warnings enabled. In Qt every module has a 'headersclean' unit test which does exactly that. While this is a good idea we're not going to assume every project has such discipline. Also some consumers may include headers with a different preprocessing context that exposes the warning. Right. Even if all headers are used by the upstream itself, this still applies. However, I still think IMPORTED=SYSTEM by *default* is a good idea, and let the edge case switch it back. I'm not seeing support for it though, so I guess I'll drop it. Somewhat echoing Brad's reply here, but it's not that I'm opposed to the idea, merely concerned that it is possible to get non-system includes when that is desired. Perhaps that is a misreading on my part, but I was getting the impression this change would make it so that imported targets can only ever be SYSTEM. I didn't really make that clear as the discussion developed, but yes, I think it makes sense to allow treating the include directories as non-system somehow, even if not by default. Then why not make INTERFACE_SYSTEM_INCLUDE_DIRECTORIES the default in the Qt imported targets and have a switch to turn them off? The code set(QT_INCLUDE_DIRS_NO_SYSTEM 1) find_package(Qt5Core) is not so bad in the edge case that needs it. I don't like it though :). I'd prefer not to have any variables that change the behavior of a find_package call, so that only one find_package is ever needed, not multiple in different directories for scope. FWIW, I agree; variables controlling find_package (except search paths) are almost always an inferior solution :-). That said... what about having a SYSTEM (and/or NO_SYSTEM) flag for find_package? This could, for config-based packages with imported targets, control the default behavior for imported include directories. I don't think that solves the problem. You might have one target which you want to treat the directories as SYSTEM, and one which you don't. I think the API for this should have target scope: A target property like set_property(TARGET foo PROPERTY IMPORTED_INTERFACE_DIRS_SYSTEM 1) and set(CMAKE_IMPORTED_INTERFACE_DIRS_SYSTEM 1) to set the default, as usual. or set_property(TARGET foo PROPERTY IMPORTED_INTERFACE_DIRS system) set_property(TARGET foo PROPERTY IMPORTED_INTERFACE_DIRS non_system) set(CMAKE_IMPORTED_INTERFACE_DIRS system) Either way, the tll() SYSTEM option could still be useful. I'll add that tomorrow. Again FWIW, a nice advantage of this is the ability to specify SYSTEM includes per target. (I'm not sure why you'd want to build one target with imported includes as SYSTEM and another not, but you could...) Yes. Even with the target property as above you could still do target_link_libraries(foo SYSTEM Bar::core) target_link_libraries(foo Bar::gui) We could also add the opposite if you want. target_link_libraries(foo NON_SYSTEM Bar::core) However, as the above already is enough for all use-cases and what we're discussing is an edge-case already, we don't need too much API for it. We can always add it later if needed. Thanks, Steve. -- 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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote: Hi Stephen, I think I need your insight of CMake code base here. According to my tests (ie ExportImport and CustomCommand), GetSourceFileWithOutput() is called with a relative path only from here: https://github.com/Kitware/CMake/blob/master/Source/cmTarget.cxx#L1939 How can I convert this name to an absolute path? Find out which of the callers of FollowName() call it with a relative path. Thanks, Steve. -- 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_link_libraries, IMPORTED targets and SYSTEM includes
Brad King wrote: On 07/25/2013 01:25 PM, Stephen Kelly wrote: Either way, the tll() SYSTEM option could still be useful. I'll add that tomorrow. Can we wait until after 2.8.12 to add this? We're already adding the new tll signature and policy CMP0023. I'd like to avoid confusion of new and old signatures w.r.t. availability of the SYSTEM option. Yes, after the follow up emails and the possible change in scope with a target property etc, I had the same idea. I don't want to add anything new to delay 2.8.12. Thanks, Steve. -- 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] link-language-static-lib topic
Brad King wrote:
Perhaps
bool LinkLanguagePropagatesToDependents() const
{ return this-TargetTypeValue == STATIC_LIBRARY; }
I think this one is fine. I've re-pushed the commit to the minor-cleanups
topic.
Thanks,
Steve.
--
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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote:
It was fastest because it was not doing the right thing. I tried to patch
it properly and the benchmark are the same whether we use the default
comparison functor or mine.
So I think you can merge it like that. I have pushed a new version without
the comment.
I still haven't tried it, but there are still style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
Thanks,
Steve.
--
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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote:
On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly
steve...@gmail.com wrote:
Nicolas Desprès wrote:
It was fastest because it was not doing the right thing. I tried to
patch it properly and the benchmark are the same whether we use the
default comparison functor or mine.
So I think you can merge it like that. I have pushed a new version
without
the comment.
I still haven't tried it, but there are still style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
Fixed and force-pushed. Sorry for the inconvenience. I am not used to this
style yet.
Your Compare::operator() contains this:
if (j == s2.rend())
{
return false;
}
return false;
Any reason not to simplify that?
Also, I don't see why the custom comparison functor is needed at all. I
removed it and sped up the test significantly. Can you explain?
Thanks,
Steve.
--
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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote: Also, I don't see why the custom comparison functor is needed at all. I removed it and sped up the test significantly. Can you explain? I had some failing tests because the previous algorithm was not a plain strcpy(). I don't see any strcpy(). Anyway, I think that's as much useful review I can do for you. I think Brad will have to do the rest. Thanks, Steve. -- 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote: So it can be used in tll() calls to link against the library (package). What makes it differ from Foo_LIBRARIES, is that CMake checks that each of the items listed in this variable * is an existing target * has the INTERFACE_INCLUDE_DIRS property set. Are you really certain it is always an error for a target to not set this? Comments ? If possible, I'd like to get that into 2.8.12. I'm still planning on getting the 'double colons for IMPORTED targets' feature in, but after 2.8.12. This is orthogonal, but the motivation is similar. My preference is to get a 2.8.12 out soon and open up for features after that. I have a few waiting for that already. Thanks, Steve. -- 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 0014317]: Configuration dependent install EXPORT
Brad King wrote: Steve, On 07/26/2013 04:43 AM, Mantis Bug Tracker wrote: http://www.cmake.org/Bug/view.php?id=14317 What do you think about adding generator expressions to install DESTINATION options. In particular the $CONFIGURATION genex would be useful in this case. Yes, $CONFIGURATION should work both before and after export. One of my goals with the INCLUDES DESTINATION feature which can not currently be realized is this: install(TARGETS foo bar bat EXPORT theTargets ... INCLUDES DESTINATION include/$TARGET_PROPERTY:NAME ) install(EXPORT theTargets NAMESPACE TP1:: ) install(FILES foo.h DESTINATION include/foo) install(FILES bar.h DESTINATION include/bar) install(FILES bat.h DESTINATION include/bat) The problem (apart from NAME not being currently a target property) is that the $TARGET_PROPERTY:NAME is reproduced verbatim in theTargetsExport.cmake. There the target names are TP1::foo etc, and include/TP1::foo does not exist. The $INSTALL_PREFIX works in the INCLUDES DESTINATION because it is replaced by preprocessing during export. A new $TARGET_NAME_PP could be introduced to make the above possible by being replaced during preprocessing too, or a target property could be populated like TARGET_BUILD_NAME. I didn't like the idea of leaking build- details to export files, and the TARGET_NAME_PP is not super elegant either, so I left the above as out of scope for now. However, similar issues could arise by adding genexes to any DESTINATION component of install, if a generator expression reads a property from a target, and that property is not exported. That's probably something that can be just documented though. For $CONFIGURATION it should be fine, but probably also involves replacing (IMPORTED_)?LOCATION(_CONFIG)? with a genex-capable LOCATION. Thanks, Steve. -- 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 --deprecated-warnings and cmake --deprecated-errors
Hi, It's now possible to invoke cmake with -DCMAKE_WARN_DEPRECATED=1 and also with -DCMAKE_ERROR_DEPRECATED=1 to get deprecation warnings or errors. I wonder if we should add --deprecated-warnings and --deprecated-errors and document them in cmake --help, as --warn-uninitialized etc? I think it's something we can do after 2.8.12, but I want to make sure it doesn't change anything in how the deprecation stuff works or is used currently. Thanks, Steve. -- 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 --deprecated-warnings and cmake --deprecated-errors
Brad King wrote: -Wdeprecated -Wdeprecated=error -Wuninitialized Ok, I'll come back to that after 2.8.12. Thanks, Steve. -- 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 0014317]: Configuration dependent install EXPORT
Brad King wrote: On 07/29/2013 06:57 PM, Stephen Kelly wrote: Yes, $CONFIGURATION should work both before and after export. So the question is how to know whether to evaluate it during export or write it literally in the file. In this case we want to expand it during export because we want $CONFIGURATION to refer to the build configuration being installed. Right. I had thought that $CONFIGURATION would be evaluated by the reader of the IMPORTED_LOCATION property on the IMPORTED target. I think you are right that it makes more sense to replace it at generate- time. The $INSTALL_PREFIX works in the INCLUDES DESTINATION because it is replaced by preprocessing during export. Does anything else get replaced by preprocessing? Target names get replaced by namespaced target names, and the INSTALL_INTERFACE or BUILD_INTERFACE gets stripped. For $CONFIGURATION it should be fine, but probably also involves replacing (IMPORTED_)?LOCATION(_CONFIG)? with a genex-capable LOCATION. The history of the LOCATION property is complicated enough already. If we do add genex support we should create a new name to distinguish it. However, why would allowing $CONFIGURATION in the destination require a genex location? We generate an install rule for a given configuration with $CONFIGURATION replaced and then put the corresponding result in IMPORTED_LOCATION_CONFIG. Yes, that makes more sense. So, the remaining question is when to evaluate the generator expressions. I agree that evaluating them at export time is a better idea. That means that I should patch the INCLUDES DESTINATION feature to do a complete evaluation, not just a preprocessing. I think that makes sense for all DESTINATION components. So, install(TARGETS foo INCLUDES DESTINATION include/$TARGET_PROPERTY:NAME) will result in include/foo in the INTERFACE_INCLUDE_DIRECTORIES of the IMPORTED target. However, set_property(TARGET foo APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES include/$TARGET_PROPERTY:NAME ) will result in include/$TARGET_PROPERTY:NAME in the INTERFACE_INCLUDE_DIRECTORIES of the IMPORTED target. That is, parameters to install(TARGETS) are evaluated at export time, and otherwise the contents of the property are reproduced verbatim. Thanks, Steve. -- 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote: Comments ? If possible, I'd like to get that into 2.8.12. Note that even in KDE there isn't consensus on whether to rely on this in the non-short term: http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80241 I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets and double-colons-means-IMPORTED. My preference is for 2.8.12 to be out soon and get those features into 2.8.13. When do you want to create 2.8.12 RC1? Thanks, Steve. -- 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 0014317]: Configuration dependent install EXPORT
Brad King wrote: On 07/30/2013 09:46 AM, Stephen Kelly wrote: That is, parameters to install(TARGETS) are evaluated at export time, and otherwise the contents of the property are reproduced verbatim. Yes, I think this makes sense. The install rules run as part of the current project's build just like custom commands, so it makes sense to evaluate generator expressions immediately. However, the implementation may be a bit complicated because now cmake_install.cmake script code will have to branch on BUILD_TYPE to pick which install rule to run. There is already infrastructure for this to support the CONFIGURATIONS option of install(TARGETS) so maybe it is okay. I think two things are being confused here. One is the DESTINATION for things that are installed by the current command. Eg: install(TARGETS foo RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) install(FILES foo.h DESTINATION include ) The bug report is about adding genex support to those destinations. The new feature is install(TARGETS foo INCLUDES DESTINATION include ) which does not result in installing anything to 'include/', but only populates a property. This is quite separate to what you describe above. I propose that we deal with what you describe above after 2.8.12. For supporting generator expressions in install(TARGETS foo INCLUDES DESTINATION include ) I've pushed a INCLUDES-DESTINATION-partial-eval topic to my clone with some ideas for it. Please let me know what you think. Thanks, Steve. -- 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 0014317]: Configuration dependent install EXPORT
Brad King wrote:
I've pushed a INCLUDES-DESTINATION-partial-eval topic to my clone with
some ideas for it. Please let me know what you think.
Are you proposing this for inclusion in 2.8.12?
Yes.
IMO it can wait along with the rest.
As INCLUDES DESTINATION is already in master, that would be a behavior
change, and probably need a policy. Currently if you use
install(TARGETS foo EXPORT fooTargets
INCLUDES DESTINATION $INSTALL_PREFIX/include/$STREQUAL:foo,bar
)
the result in fooTargets.cmake is
INTERFACE_INCLUDE_DIRECTORIES
${_IMPORT_PREFIX}/include/$STREQUAL:foo,bar
if the genex is evaluated at export time in a follow-up release, the result
would instead be
INTERFACE_INCLUDE_DIRECTORIES
${_IMPORT_PREFIX}/include/0
So, I think for the case of INCLUDES DESTINATION, we can either decide and
fix it now, or revert the change adding it for 2.8.12.
I forgot, which config-related generator expressions on imported
targets honor MAP_IMPORTED_CONFIG_CONFIG?
The $CONFIG:cfg expression should always process those, if used on any of
the target properties used for the interface.
What is the behavior when a not-allowed expression like
STREQUAL is used? Does it produce an error message?
In master the STREQUAL is reproduced verbatim. In my topic it is evaluated
at export time.
Thanks,
Steve.
--
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 0014317]: Configuration dependent install EXPORT
Brad King wrote: The bug report is about adding genex support to those destinations. Yes, it's also the one that started this thread. Do we agree that full generate-time evaluation is appropriate for these? If so then the implementation will require BUILD_TYPE conditional blocks in generated cmake_install.cmake files. I don't know yet. I haven't looked into the generated cmake_install.cmake files. Thanks, Steve. -- 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 and empty lists
Brad King wrote:
What about the tll() version?
target_link_libraries(foo PRIVATE )
seems to not be an error with master already.
Changing that behavior is something I'd recommend deferring to after
2.8.12 if you want to change it. I don't feel extremely strongly about
keeping it strict.
How intrusive is the change?
It might be as simple as
diff --git a/Source/cmTargetPropCommandBase.cxx
b/Source/cmTargetPropCommandBase.cxx
index 287ce46..37aa604 100644
--- a/Source/cmTargetPropCommandBase.cxx
+++ b/Source/cmTargetPropCommandBase.cxx
@@ -19,7 +19,7 @@ bool cmTargetPropCommandBase
::HandleArguments(std::vectorstd::string const args, const char *prop,
ArgumentFlags flags)
{
- if(args.size() 3)
+ if(args.size() 2)
{
this-SetError(called with incorrect number of arguments);
return false;
@@ -53,7 +53,7 @@ bool cmTargetPropCommandBase
if ((flags PROCESS_SYSTEM) args[argIndex] == SYSTEM)
{
-if (args.size() 4)
+if (args.size() 3)
{
this-SetError(called with incorrect number of arguments);
return false;
@@ -65,7 +65,7 @@ bool cmTargetPropCommandBase
bool prepend = false;
if ((flags PROCESS_BEFORE) args[argIndex] == BEFORE)
{
-if (args.size() 4)
+if (args.size() 3)
{
this-SetError(called with incorrect number of arguments);
return false;
... but I haven't tried most of the arg combinations.
I don't want to make people wait for
2.8.13 just to avoid creating conditions like
if(mylist)
target_include_directories(... PUBLIC ${mylist})
endif()
Ok, I'll add a test for the above patch and submit that.
Thanks,
Steve.
--
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 0014317]: Configuration dependent install EXPORT
Brad King wrote:
So, I think for the case of INCLUDES DESTINATION, we can either decide
and fix it now, or revert the change adding it for 2.8.12.
Let's try to decide now and revert as a last resort.
So the only reason we need partial evaluation is to leave
configuration-dependent sub-expressions untouched since the
configuration is not known until generation of the consumer?
Yes, I think that is the case.
Includes are not generally different files for debug/release as the
preprocessor is generally used instead where needed. However, let's assume
that for the debug config we install a foo_debug.h, and otherwise not.
To get more concrete, here's some cases I could think of:
A) I want to install all includes to
set(config_suffix $$CONFIG:Debug:debug$NOT:$CONFIG:Debug:release)
INCLUDES DESTINATION $INSTALL_PREFIX/include/${config_suffix}
and for consumers of the target to get either the 'debug' or the 'release'
include directory.
I would use
install(FILES ${files}
DESTINATION include/${config_suffix})
(when that works) to install the files.
B) I only want to install the foo_debug.h to a special location
install(FILES ${files}
DESTINATION include)
install(FILES foo_debug.h
DESTINATION include/debug
CONFIGURATIONS Debug
)
INCLUDES DESTINATION
include;$$CONFIG:Debug:$INSTALL_PREFIX/include/debug
So that consumers get both include directories. This probably works already
with master.
C) As B, but with target-named include paths
install(FILES ${foo_files}
DESTINATION include/foo)
install(FILES ${bar_files}
DESTINATION include/bar)
install(FILES foo_debug.h
DESTINATION include/foo/debug
CONFIGURATIONS Debug
)
set(basic_path $INSTALL_PREFIX/include/$TARGET_PROPERTY:NAME)
INCLUDES DESTINATION
${basic_path}
$$CONFIG:Debug:${basic_path}/debug
This does not work with master. However, there is a workaround.
target_include_directories(foo INTERFACE
include/foo
$$CONFIG:Debug:$INSTALL_PREFIX/include/foo/debug
)
ie, not using the INCLUDES DESTINATION feature, which is 'just' a
convenience for the 'common case'.
I think the partial evaluation should work by traversing
the expression tree and collapsing sub-tree that does not
depend on the configuration into a leaf node with a constant
value.
Alternatively we could generate an error if any config-dependent
expressions are found in INCLUDES DESTINATION and otherwise
do full evaluation. That way we can decide on the partial
evaluation semantics later.
Yes, such an error would be quite easy to generate, as that fact is already
recorded. I considered that and decided not to implement it because the bug
report specifically wanted config support. However, that was for libraries,
not includes. Config sensitive dirs are likely more common for libraries
than includes, so actually I think it would be fine to make that an error
and always do full evaluation.
I've pushed INCLUDES-DESTINATION-no-config to my clone with an
implementation. Can I merge it to next?
Thanks,
Steve.
--
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 0014317]: Configuration dependent install EXPORT
Brad King wrote:
On 07/31/2013 11:05 AM, Stephen Kelly wrote:
Config sensitive dirs are likely more common for libraries
than includes, so actually I think it would be fine to make that an error
and always do full evaluation.
To clarify, the no-config rule is for INCLUDES DESTINATION only, but full
with-config evaluation will be allowed for a real DESTINATION. The
config can be honored for file destinations. For targets we generate
a per-config IMPORTED_LOCATION_CONFIG anyway. We will wait for after
2.8.12 for the file destination generator expressions.
Right.
I've pushed INCLUDES-DESTINATION-no-config to my clone with an
implementation. Can I merge it to next?
Yes, but one comment first:
+ if (cge-GetHadContextSensitiveCondition())
+{
+cmMakefile* mf = target-GetMakefile();
+cmOStringStream e;
+e Target \ target-GetName() \ is installed with
+INCLUDES DESTINATION set to a configuration sensitive path. This is
Does context sensitive condition ever mean something other than
configuration sensitive? If so then users may produce a case that
triggers this error in a confusing manner.
Yes, is also means that TARGET_POLICY was used, or a
LINK_INTERFACE_DEPENDENT_{BOOL,STRING} property was used in the generator
expression.
In the case of the target policy, it makes sense to error on this because
there is no point in changing the property based on the policy setting of
the consumer of the IMPORTED target.
For LINK_INTERFACE_DEPENDENT_STRING properties it is a bit unfortunate,
because we can't use the QT_MAJOR_VERSION target property and install to
either include/Qt4Based or include/Qt5Based depending on which version we're
installing for.
However, that is still easily possible with target_include_directories.
Thanks,
Steve.
--
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] Alias targets for 2.8.12
Hi there, it would be useful for KDE Frameworks to have ALIAS targets in CMake 2.8.12. http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80247 I finished the topic and pushed it to next in case it can go into that release. I won't be available most of today to change it if needed, but I can fix it up tomorrow if needed. Thanks, Steve. -- 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] Alias targets for 2.8.12
Brad King wrote: The topic looks like a great start. I won't promise to take it for 2.8.12 yet but let's proceed with review. - The documentation in add_library and add_executable lists a bunch of things one can't do but not an example of what one can do. I think this documentation should have an explicit list of what is intended and allowed and then exclude everything else. That way if we missed a use case we can treat it as a bug later and add the error case. I'm not sure how to do this one. Do you want an example code snippet of allowed commands? - Should add_executable be (dis)allowed to add a library alias, and vice-versa for add_library? Yes, done. - The documentation does not mention that alias targets cannot be installed or exported. Fixed. - Add more positive use cases (or negative if not allowed) to the test suite: - add_custom_command/add_custom_target COMMAND argv0 translation - add_test NAME/COMMAND signature argv0 translation - generator expression references e.g. $TARGET_FILE:... in add_test and add_custom_* commands - Alias for an object library with $TARGET_OBJECTS:... All done. - Look for other uses of cmMakefile FindTargetToUse and FindTarget; all of them need tests for alias behavior and/or should be preceded by !IsAlias checks (many are already done). Reviewed. I think everything is covered. - How does this interact with $TARGET_PROPERTY:NAME? The name of the aliased target is returned, not the alias name itself. - When if(TARGET xyz) returns true how can one tell from CMake code whether xyz is an alias or a real target? Can one get the real target if it is an alias? I added a ALIASED_TARGET target property for that. An alternative would be if(ALIAS xyz) but I don't think that's really needed. if() is complex enough already. Thanks, Steve. -- 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] Alias targets for 2.8.12
Brad King wrote: On 08/02/2013 08:00 AM, Brad King wrote: No, I think just a prose list of example uses e.g. linking into other targets. Thanks for the other fixes. FYI, I added this to your topic: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a0a1945 to fix the AliasTarget test on Watcom. Please squash that into the appropriate commit in the next revision of the topic. Thanks. I've added the extra prose documentation now too. I think all the follow up commits should be squashed into the initial commit. I've only kept them separate until now to simplify review. Will I go ahead and squash it all together now? Thanks, Steve. -- 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote:
On Monday 29 July 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
So it can be used in tll() calls to link against the library (package).
What makes it differ from Foo_LIBRARIES, is that CMake checks that each
of the items listed in this variable
* is an existing target
* has the INTERFACE_INCLUDE_DIRS property set.
Are you really certain it is always an error for a target to not set
this?
I think so.
If I want to use symbols from a library, I should include its headers, and
for that the include dirs need to be known.
For header-only libraries even more.
Are there cases where this is not the case ?
There will/can be in the future.
add_library(picon INTERFACE)
set_property(TARGET picon INTERFACE_POSITION_INDEPENDENT_CODE ON)
add_library(picoff INTERFACE)
set_property(TARGET picoff INTERFACE_POSITION_INDEPENDENT_CODE ON)
...
# Use linking to psuedo targets to enable compiler options:
add_executable(foo main.cpp)
target_link_libraries(foo PRIVATE picon)
add_executable(bar main.cpp)
target_link_libraries(bar PRIVATE picoff)
Or:
add_library(cxx11features INTERFACE)
set_property(TARGET cxx11features
INTERFACE_COMPILE_OPTIONS
$$CXX_COMPILER_ID:GNU:-std=c++0x
$$CXX_COMPILER_ID:Clang:-std=c++11
)
set(IS_GNU $CXX_COMPILER_ID:GNU)
set(IS_46 $VERSION_GREATER:$CXX_COMPILER_VERSION,4.6)
set_property(TARGET cxx11features
INTERFACE_COMPILE_DEFINITIONS
$$AND:${IS_GNU},${IS_46}:CXXFEATURES_NULLPTR_FOUND
)
# Possibly also specify libcxx compiler option if using
# recent clang on apple.
...
add_executable(foo main.cpp)
target_link_libraries(foo cxx11features)
Thanks,
Steve.
--
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] Please review CXXFeatures.cmake
Rolf Eike Beer wrote: Am Sonntag, 28. April 2013, 13:57:26 schrieb Rolf Eike Beer: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: Ok, I finally put it into the CMake repository: I have some feedback: 1) A recent commit in the topic does this: -g++ seems to support constexpr since 4.5 even if their support page says 4.6 It has been common for compilers to implement support for features like this, but have some fundamental brokenness in earlier versions. Your test which enables the use of constexpr might not exercise the feature enough to hit the fundamental brokenness, but that doesn't mean it's an edge-case. It would be better not to second-guess the version gcc says it supports features in. 2) Given that you're gathering the versions of each feature availability anyway, and given that boost.config and qcompilerdetection.h have the same information, there is no need for all users of the module to run all these try_compiles for all projects. Think of the energy waste :)! I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. 3) CXX11_COMPILER_FLAGS is not really the 'modern' way to specify compiler flags, as of recent CMake versions. See for example the reasoning here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6876/focus=6890 regarding *_FLAGS, which is a whitespace delimited string, and COMPILE_OPTIONS, which is a regular ';' delimited CMake list. The modern way to do something like that is a target property and a way to set the default. See for example commit bd3496300262bd26073ce03e020731c592249148 (Refactor generation of shared library flags, 2012-05-30). The set(CMAKE_POSITION_INDEPENDENT_CODE ON) feature is enabled by this-SetPropertyDefault(POSITION_INDEPENDENT_CODE, 0); in cmTarget. For more/similar, see commit cd1fa537a03377974a4d0a27e592785f931a41e5 (Add a COMPILE_OPTION for a VISIBILITY_INLINES_HIDDEN target property., 2013-05-23) and 0e9f4bc00c6b26f254e74063e4026ac33b786513 (Introduce target property LANG_VISIBILITY_PRESET, 2013-05-18). I added a patch to my clone with the start of CMAKE_CXX_COMPILE_OPTIONS_STD_CXX11 https://gitorious.org/~steveire/cmake/steveires-cmake/commits/std-cxx-target-property but it didn't get anywhere yet: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4106 4) The COMPILE_OPTIONS for clang+apple might have to include -stdlib=libc++ for binary compatibility reasons if any of the dependencies use c++11 std library API in their interface and use libc++. See what I wrote about that here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 5) This is not nice API: #if defined (CXXFEATURES_NULLPTR_FOUND) void *nix = nullptr; #else /* CXXFEATURES_NULLPTR_FOUND */ void *nix = 0; #endif /* CXXFEATURES_NULLPTR_FOUND */ Much better would be: void *nix = CXXFEATURES_NULLPTR; where -DCXXFEATURES_NULLPTR=0 or -DCXXFEATURES_NULLPTR=nullptr. See what Qt does for other similar API decisions on what should be defined to something (like nullptr, constexpr, final etc), and what should be a 'guard' define like above (eg lambdas, variadic templates etc). Note also that by defining the CXXFEATURES_FINAL to something, you get to use the 'sealed' extension, which does the same thing, and works with VC2005. See qcompilerdetection.h. 6) It is also unfortunate that because your solution is to define things on the command line, you can't easily define something for static_assert. See CMakeStaticAssert for example, which works for all compilers on the dashboard. For that reason, I'll continue to recommend that anyone using Qt and CMake does not use your module, but instead uses the defines from Qt. Ditto for anyone using boost. A missing piece that your module provides is determining the features at CMake time. However, if Qt is found, that can be done with a single try_compile of qglobal.h to get that information into a form usable to CMake. That's a feature I can add to Qt 5 soon, and something similar can be done to process the information from boost.config. Thanks, Steve -- 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] Please review CXXFeatures.cmake
Rolf Eike Beer wrote: Given that you're gathering the versions of each feature availability anyway, and given that boost.config and qcompilerdetection.h have the same information, there is no need for all users of the module to run all these try_compiles for all projects. Think of the energy waste :)! I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. We already found out that this is a bad idea for Apple, No we didn't :). The AppleClang vs VanillaClang version issue is something that needs to be solved anyway. I still don't completely get it right for g++ and XL, and it isn't the way that CMake works for other things (I'm thinking of e.g. OpenMP). And qcompilerdetection.h is a good example of how I would not want it, last time I looked they just deactivated every feature on Clang. I don't know what you're talking about, but I am certain you're mistaken in a simple interpretation of what you wrote. The idea I have about CMake is that it would check for stuff on any compiler I throw on it, so it would just report correct results for this that haven't been tested before (PGI? MipsPro? gcc 2?). ... Stephen Kelly wrote: I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. ... 4) The COMPILE_OPTIONS for clang+apple might have to include -stdlib=libc++ for binary compatibility reasons if any of the dependencies use c++11 std library API in their interface and use libc++. See what I wrote about that here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 I don't see how this is different with and without C++11, so how does it affect this module in a way that would not affect the user anyway? You might have to investigate, for example, how system c++ libraries are compiled. I'm not familiar enough with APPLE to know what kind of c++ libraries it comes with. Thanks, Steve. -- 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] Please review CXXFeatures.cmake
Rolf Eike Beer wrote: Stephen Kelly wrote: Rolf Eike Beer wrote: Given that you're gathering the versions of each feature availability anyway, and given that boost.config and qcompilerdetection.h have the same information, there is no need for all users of the module to run all these try_compiles for all projects. Think of the energy waste :)! I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. We already found out that this is a bad idea for Apple, No we didn't :). The AppleClang vs VanillaClang version issue is something that needs to be solved anyway. The which c++ lib is used one, too. So you can only score one point, either this one or the one below ;) Not really. The set of language features implemented by the compiler is independent of the stdlib implementation and completeness. 4) The COMPILE_OPTIONS for clang+apple might have to include -stdlib=libc++ for binary compatibility reasons if any of the dependencies use c++11 std library API in their interface and use libc++. See what I wrote about that here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 I don't see how this is different with and without C++11, so how does it affect this module in a way that would not affect the user anyway? You might have to investigate, for example, how system c++ libraries are compiled. I'm not familiar enough with APPLE to know what kind of c++ libraries it comes with. Again, how does that affect this module? Yes, I see what you mean. I suppose this issue of std library implementation is orthogonal to your module. However, I think a complete 'CMake support for c++11' concept would include diagnostic of transitively incompatible stdlib implementations (because it can be a common problem nowadays as both libstdcxx and libcxx are in the wild as c++11 library implementations), *and* compiler feature enabling. I guess you're only shooting for the latter, and not the 'complete package', but as I wrote before, I still think you should modernize regarding COMPILE_OPTIONS and target properties anyway. Thanks, Steve. -- 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] QNX QCC and _CMAKE_TOOLCHAIN_PREFIX
Hi there,
I can use a trivial toolchain file to compile for QNX with qcc:
SET(CMAKE_SYSTEM_NAME QNX)
SET(arch gcc_ntoarmv7le)
SET(CMAKE_C_COMPILER qcc -V${arch})
SET(CMAKE_CXX_COMPILER QCC -V${arch})
SET(CMAKE_FIND_ROOT_PATH $ENV{QNX_TARGET}/armle-v7 $ENV{QNX_TARGET})
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
However, I just noticed that when I build, /usr/bin/ar is used instead of
/home/stephen/bbndk/host_10_1_0_132/linux/x86/usr/bin/ntoarm-ar
When cross-compiling with g++, the _CMAKE_TOOLCHAIN_PREFIX is set by
examining the name of the compiler in CMakeDetermineCXXCompiler.cmake.
When using qcc, the COMPILER_BASENAME doesn't match, and the appropriate
prefix is not encoded into the name anyway. I was thinking that
CMakeDetermineCXXCompiler.cmake could be extended to handle QCC and use the
CMAKE_CXX_COMPILER_TARGET.
However, currently the CMAKE_CXX_COMPILER_TARGET needs to be of the form
gcc_ntoarch, not just ntoarch, so the QNX specific code in
CMakeDetermineCXXCompiler.cmake would have to account for that, and other
possible suffixes (the version is optional):
stephen@hal:~/bbndk/host_10_1_0_132/linux/x86/usr/bin$ ./QCC -V
cc: targets available in
/home/stephen/bbndk/host_10_1_0_132/linux/x86/etc/qcc:
4.6.3,gcc_ntoarmv7le_gpp
4.6.3,gcc_ntox86_gpp
4.6.3,gcc_ntox86_cpp
4.6.3,gcc_ntoarmv7le_cpp-ne
4.6.3,gcc_ntoarmv7le
4.6.3,gcc_ntox86_cpp-ne
4.6.3,gcc_ntox86(default)
4.6.3,gcc_ntoarmv7le_cpp
Can I extend the CMakeDetermineCXXCompiler.cmake with handling for that?
That would mean that with a recent enough cmake version, I can replace the
SET(arch gcc_ntoarmv7le)
SET(CMAKE_C_COMPILER qcc -V${arch})
SET(CMAKE_CXX_COMPILER QCC -V${arch})
in my toolchain file with
SET(arch gcc_ntoarmv7le)
SET(CMAKE_C_COMPILER qcc)
SET(CMAKE_CXX_COMPILER QCC)
SET(CMAKE_C_COMPILER_TARGET ${arch})
SET(CMAKE_CXX_COMPILER_TARGET ${arch})
and it will 'just work'.
I also notice that CMakeDetermineCXXCompiler.cmake doesn't have specific
handling for clang, and it could be extended similarly. Note that there are
two ways to use clang as a cross-compiler. One is specifying -target, which
CMAKE_C_COMPILER_TARGET does, and the other is creating a symlink or copy so
that the name contains the triple:
stephen@hal:/tmp$ /usr/bin/clang -dumpmachine
x86_64-pc-linux-gnu
stephen@hal:/tmp$ ln -s clang arm-linux-gnueabihf-clang
stephen@hal:/tmp$ ./arm-linux-gnueabihf-clang -dumpmachine
arm--linux-gnueabihf
So, possibly both ways should be handled in the clang case. I haven't
actually done any testing for the clang cases yet though to find out if the
missing _CMAKE_TOOLCHAIN_PREFIX causes a problem. I don't recall ever
hitting any, which confuses me somewhat.
Thanks,
Steve.
--
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] Targets for FindGTK2.cmake
Brad King wrote:
On 08/06/2013 05:39 AM, Daniele E. Domenichelli wrote:
I added a commit introducing a couple of unit tests that should run only
if GTK and/or GTKMM are available on the system.
Thanks. Steve, please take a quick look at this topic to
review how the imported targets are constructed.
Here's my remarks:
* Using double-semicolons. Good.
* Release and debug libraries handled. Good.
* Release listed before Debug. Good. RelWithDebInfo etc should work.
* What is GTK2_GDKCONFIG_INCLUDE_DIR compared to GTK2_GDK_INCLUDE_DIR? Can
you conditionally append GTK2_GDKCONFIG_INCLUDE_DIR if it is not STREQUAL
GTK2_GDK_INCLUDE_DIR?
* Populating the INTERFACE_COMPILE_DEFINITIONS can be wrapped in
if(GTK2_DEFINITIONS) as it is only set when using msvc with two of the
targets. No need to set it to an empty string in all other cases.
* set(GTK2_${_var}_LIBRARY GTK2::${_basename} PARENT_SCOPE) seems to
override the user variable for the library and makes it impossible for the
user to set the library location by overriding the cache, right?
This line should not be needed anyway. I guess you want
if (GTK2_USE_IMPORTED_TARGETS)
list(APPEND GTK2_LIBRARIES GTK2::${basename})
else()
list(APPEND GTK2_LIBRARIES ${GTK2_${_var}_LIBRARY})
endif()
instead.
However, even then I don't recommend it. I'd say document that users should
use the imported target names directly if they want. Alex disagrees of
course, and would want you to populate a LIBRARY_TARGETS variable (I don't
see the point). I guess this change is not 2.8.12 material anyway though, so
maybe we'll finally sort all that out for in the next release anyway.
* CMake 2.8.12 will ignore IMPORTED_LINK_INTERFACE_LIBRARIES_${_config}, so
you don't need to set it. The only reason to want to set it is if you want
people to backport this updated module. I don't recommend setting it.
* The diff contains this:
+#_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
+_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
* If GObject depends on glib, then the line
_GTK2_ADD_TARGET_DEPENDS(ATK gobject glib) does not need to specify glib. I
would minimise those dependency listings.
* fontconfig seems to be only a compile dependency but not a link
dependency.
* freetype seems to be a link dependency (I assume, as it is added to
GTK2_LIBRARIES), but the library does not seem to be in the link interface
of the Cairo library. ${FREETYPE_LIBRARIES} can just be added to the
INTERFACE_LINK_LIBRARIES, but I think it might make sense to create an
imported target for it too anyway (in FindFreetype.cmake)?
* Thanks for the initiative. I have patches for zlib and png adding imported
targets, but I'm waiting for
http://public.kitware.com/Bug/view.php?id=14082. I'd like to add imported
targets to most Find modules shipped with cmake eventually.
Thanks,
Steve.
--
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] Targets for FindGTK2.cmake
Daniele E. Domenichelli wrote:
Hello Stephen,
Thanks for the review
On 09/08/13 10:50, Stephen Kelly wrote:
* What is GTK2_GDKCONFIG_INCLUDE_DIR compared to GTK2_GDK_INCLUDE_DIR?
Can you conditionally append GTK2_GDKCONFIG_INCLUDE_DIR if it is not
STREQUAL GTK2_GDK_INCLUDE_DIR?
GTK2 has config files that usually are not in the same directory as
the other include files. Therefore there are 2 different variables, and
both needs to be included (for example gdk/gdk.h includes
gdk/gdktypes.h that includes gdkconfig.h)
I will add a check to ensure that the same path is not added twice (even
though I didn't see any system where they are the same)
Ok, probably no need for the additional STREQUAL check then.
* set(GTK2_${_var}_LIBRARY GTK2::${_basename} PARENT_SCOPE) seems to
override the user variable for the library and makes it impossible for
the user to set the library location by overriding the cache, right?
This is something I took from FindQT4.cmake...
The GTK2_${_var}_LIBRARY are not cached, it is generated from
GTK2_${_var}_LIBRARY_DEBUG and GTK2_${_var}_LIBRARY_RELEASE (that are
cached). The user can override these 2 variables, and they will end in
the target and in the GTK2_${_var}_LIBRARY variable
Ok, thanks for the explanation. I'm sure that's fine then.
The difference is that if GTK2_USE_IMPORTED_TARGETS the
GTK_${_var}_LIBRARY will link the target (and it's dependencies)
otherwise it will link only the library (without dependencies) using the
DEBUG or RELEASE version, depending on what was found.
Are there also GTK_${_var}_LIBRARIES variables?
Conventionally, the *LIBRARIES variables are for user-use and the *LIBRARY
variables are not...
I think it can be useful during a transition from variables to targets...
Does it sound wrong?
It's probably ok.
* CMake 2.8.12 will ignore IMPORTED_LINK_INTERFACE_LIBRARIES_${_config},
so you don't need to set it. The only reason to want to set it is if you
want people to backport this updated module. I don't recommend setting
it.
Does this mean that setting the INTERFACE_LINK_LIBRARIES is enough?
Again I took this from FindQT4...
Yes, I didn't remove it from there yet. I do intend to though probably after
CMake 2.8.12.
To be honest want to be able to backport the module, even though not the
target part (INTERFACE_INCLUDE_DIRECTORIES won't work anyway afaik), so
I can remove the
Something missing here, but if backporting is the motivation, I can see the
reasoning. No need to remove the
IMPORTED_LINK_INTERFACE_LIBRARIES_${_config} if you don't want to.
* The diff contains this:
+#_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
+_GTK2_ADD_TARGET_DEPENDS(GOBJECT glib)
It should be already removed in one of the following commits,
Indeed. I looked again at git diff stage/master...stage/FindGTK2-targets and
didn't find that chunk. Odd. I thought that's what I did before too...
I'm not
sure if it is possible to squash commits/rebase topics published and
merged to next.
It's possible, but a bit tricky. If you rebase, the result of the rebasing
needs to be the exact same as what is already in next. When fixing up a
branch, that means making fixup commits, then pushing them, then squashing
the fixes with a rebase, then force pushing. You can test the merge to
stage/next locally too.
* If GObject depends on glib, then the line
_GTK2_ADD_TARGET_DEPENDS(ATK gobject glib) does not need to specify glib.
I would minimise those dependency listings.
atk explicitly requires glib (glib.h is included in some headers)
therefore I thought it was better to make this explicit here as well.
*shrug*. I've seen the same argument presented before, but I don't agree
with it. As you wish.
Does this add the glib target twice?
I'm not sure. Even if it does, that shouldn't be harmful.
* fontconfig seems to be only a compile dependency but not a link
dependency.
* freetype seems to be a link dependency (I assume, as it is added to
GTK2_LIBRARIES), but the library does not seem to be in the link
interface of the Cairo library. ${FREETYPE_LIBRARIES} can just be added
to the INTERFACE_LINK_LIBRARIES, but I think it might make sense to
create an imported target for it too anyway (in FindFreetype.cmake)?
To be honest I'm not completely sure here... On windows (with the GtkMM
installer) I'm having some issues with freetype, when linking
${GTK2_LIBRARIES}, but it links when I use the libraries one by one.
It would be interesting to get more information on this.
On the other hand, pkg-config --libs gtk+-2.0 on my system reports
that the freetype library is required, even though the headers does not
seem to ... (I'm still investigating this).
Also for fontconfig it looks like that it doesn't need to be linked,
even though pkg-config reports so...
Ok.
By the way, fontconfig is a freedesktop package, it is not part of GTK,
does it sound reasonable to create
Re: [cmake-developers] Please review CXXFeatures.cmake
Rolf Eike Beer wrote:
5)
This is not nice API:
#if defined (CXXFEATURES_NULLPTR_FOUND)
void *nix = nullptr;
#else /* CXXFEATURES_NULLPTR_FOUND */
void *nix = 0;
#endif /* CXXFEATURES_NULLPTR_FOUND */
Much better would be:
void *nix = CXXFEATURES_NULLPTR;
where -DCXXFEATURES_NULLPTR=0 or -DCXXFEATURES_NULLPTR=nullptr.
See what Qt does for other similar API decisions on what should be
defined to something (like nullptr, constexpr, final etc), and what
should be a 'guard' define like above (eg lambdas, variadic templates
etc).
Note also that by defining the CXXFEATURES_FINAL to something, you get to
use the 'sealed' extension, which does the same thing, and works with
VC2005. See qcompilerdetection.h.
The module returns just a list of CMake flags. How this is passed to the
user (header, defines, whatever) is currently something the user must
decide. I will not do anything fancy in the testcase for now.
Imagine I wanted to set Grantlee_FINAL to empty or final based on whether
c++11 was active or not. How would I do that?
I might do this:
# This seems like an API smell. With g++ I want to wrap the add_definitions
# in a condition for enabling c++11 at all. Does this mean that c++11
# features are not made available when using MSVC?
if(CXX11_COMPILER_FLAGS)
# Can't use add_compile_options as CXX11_COMPILER_FLAGS is a string, not
# a list.
# This means that -std=c++11 is also passed when linking.
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${CXX11_COMPILER_FLAGS})
if (CXXFeatures_class_override_final_FOUND)
add_definitions(-DGrantlee_FINAL=final)
set(_final_defined 1)
endif()
endif()
if (NOT _final_defined)
add_definitions(-DGrantlee_FINAL=)
endif()
Do you have any more-real-world examples of what code using your module
would look like?
My c++ code would then look like:
struct A Grantlee_FINAL
{
int data;
};
However, now downstreams need to define Grantlee_FINAL to something in order
to compile. We can help of course by putting Grantlee_FINAL in the
INTERFACE_COMPILE_DEFINITIONS of Grantlee.
However, what do we define it to? We need to define it based on the
capabilities of the downstream. Ok, the way to do things like that in CMake
is generator expressions.
target_compile_definitions(Grantlee
INTERFACE Grantlee_FINAL=$$TARGET_PROPERTY:CXX11:final
)
So, if the consumer has the CXX11 property ON, then it will be defined to
'final'.
However, the problem is that there is no standard CXX11 target property. At
best, I'd choose a property name which is a de-facto standard. See point 3:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7671
To repeat my point 5, the target_compile_definitions code might look more
like this:
set(msvc_genex $STREQUAL:$COMPILER_ID,MSVC)
set(msvc_sealed_min $NOT:$VERSION_LESS:$CXX_COMPILER_VERSION,1400)
set(msvc_sealed_max $VERSION_LESS:$CXX_COMPILER_VERSION,1700)
set(msvc_sealed $AND:${msvc_genex},${msvc_sealed_min},${msvc_sealed_max})
set(_use_sealed $AND:$TARGET_PROPERTY:CXX11,${msvc_sealed})
set(_use_final $AND:$TARGET_PROPERTY:CXX11,$NOT:${msvc_sealed})
set(cxx11_final $${_use_final}:final$${_use_sealed}:sealed)
target_compile_definitions(Grantlee
INTERFACE Grantlee_FINAL=${cxx11_final}
)
See https://qt.gitorious.org/qt/qtbase/commit/37a660c594a
I really think that's something that should be solved by your module. I
still think you should revisit my review mail on point 2 too.
Thanks,
Steve.
--
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] Please review CXXFeatures.cmake
Stephen Kelly wrote: I still think you should revisit my review mail on point 2 too. Something that becomes possible when thinking about the above and target properties is interface requirements. If my library uses 'final' unguarded by macros in my headers, then I want to communicate through the target that a compiler supporting that feature is required. set_property(TARGET foo PROPERTY INTERFACE_CXX_COMPILER_FEATURE_final 1) which would work similiarly to (and using the same infrastructure as) INTERFACE_POSITION_INDEPENDENT_CODE. Thanks, Steve. -- 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] Targets for FindGTK2.cmake
Daniele E. Domenichelli wrote:
On 12/08/13 15:36, Stephen Kelly wrote:
The difference is that if GTK2_USE_IMPORTED_TARGETS the
GTK_${_var}_LIBRARY will link the target (and it's dependencies)
otherwise it will link only the library (without dependencies) using the
DEBUG or RELEASE version, depending on what was found.
Are there also GTK_${_var}_LIBRARIES variables?
Conventionally, the *LIBRARIES variables are for user-use and the
*LIBRARY variables are not...
Not at the moment, but perhaps it might be useful to add them... What do
you think?
My personal view is that you should recommend people to use the target names
directly and not the variables :), but I know that view is not universally
shared.
I tried locally but I get merge conflicts, so I'm not sure if I'm doing
it right... If it is not an issue, I'd just leave the extra commit.
Brad can squash up your branch before merging to master if he wants to.
* If GObject depends on glib, then the line
_GTK2_ADD_TARGET_DEPENDS(ATK gobject glib) does not need to specify
glib. I would minimise those dependency listings.
atk explicitly requires glib (glib.h is included in some headers)
therefore I thought it was better to make this explicit here as well.
*shrug*. I've seen the same argument presented before, but I don't agree
with it. As you wish.
I'm not expert, I'm just saying what I thought when I wrote it, so if
you think it is better in the other way I can change it.
I think that's your call as the maintainer or Brads call.
* fontconfig seems to be only a compile dependency but not a link
dependency.
* freetype seems to be a link dependency (I assume, as it is added to
GTK2_LIBRARIES), but the library does not seem to be in the link
interface of the Cairo library. ${FREETYPE_LIBRARIES} can just be added
to the INTERFACE_LINK_LIBRARIES, but I think it might make sense to
create an imported target for it too anyway (in FindFreetype.cmake)?
To be honest I'm not completely sure here... On windows (with the GtkMM
installer) I'm having some issues with freetype, when linking
${GTK2_LIBRARIES}, but it links when I use the libraries one by one.
It would be interesting to get more information on this.
I did a few more tests, and it looks like that, at least on my system
and on windows, FREETYPE_LIBRARIES are not required, they are linked to
some other libraries (i.e. cairo) but they don't need to be linked
explicitly
On the other hand, the FREETYPE_INCLUDE_DIR is required, because some
public header includes freetype headers.
Can you confirm that the things used in those cases from the headers are
only defines, enum values, inline functions etc, and not anything that
becomes part of the ABI (such as inheriting from a type etc)? Or, otherwise,
can you determine why the freetype header is in the public headers?
On window using gtkmm installer, find_package(Freetype) freetype is not
found, FREETYPE_FOUND is FALSE, FREETYPE_LIBRARY is
FREETYPE_LIBRARY-NOTFOUND, but FREETYPE_INCLUDE_DIR is set correctly
(the headers are installed, but the .lib file is missing)
I'm not sure if this is a bug in FindFreetype (FREETYPE_INCLUDE_DIR
should be unset if freetype was not found?)
Perhaps. If so, maybe that's something FPHSA should do? Seems like a
separate topic though.
Do you mean that the windows gtk installer does not install the .lib file at
all, but does install the include files (because it only uses defines/enums
and doesn't need to link to the thing?)?
On the other hand, fixing this means that building gtk programs will
fail. Perhaps FindGTK2 should NOT use FindFreetype and should look for
the headers only internally (like for fontconfig)
It seems so, yes.
Btw, was there any effort to get the gtk upstream to produce cmake config
files with IMPORTED targets?
Thanks,
Steve.
--
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] Version number updates for 2.8.12
Hi, I pushed a branch updating the version number of new policies and a version number generated in export files a few months ago. I just left it as a reminder to bump merge the bumps at RC time. The branch was deleted soon after though. Is the release branch going to get a similar change for the RC1? Thanks, Steve. -- 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] Version number updates for 2.8.12
Brad King wrote: I added a commit to update the versions: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07c16eec I'll have to re-create the release branch tomorrow after this is tested. You missed the version in Source/cmExportInstallFileGenerator.cxx See commit 574fec97fd011 Thanks, Steve. -- 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] Version number updates for 2.8.12
Brad King wrote: On 08/14/2013 10:59 AM, Stephen Kelly wrote: Brad King wrote: I added a commit to update the versions: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07c16eec I'll have to re-create the release branch tomorrow after this is tested. You missed the version in Source/cmExportInstallFileGenerator.cxx See commit 574fec97fd011 Please extend the topic to fix that. I'll squash it later. That breaks the ExportImport unit test, because is is used in a version_greater check and the version bump to 2.8.12 is only in the release branch. We sort-of discussed this before: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6442 Thanks, Steve. -- 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] Version number updates for 2.8.12
Brad King wrote: On 08/14/2013 11:00 AM, Brad King wrote: On 08/14/2013 10:59 AM, Stephen Kelly wrote: Brad King wrote: I added a commit to update the versions: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07c16eec I'll have to re-create the release branch tomorrow after this is tested. You missed the version in Source/cmExportInstallFileGenerator.cxx See commit 574fec97fd011 Please extend the topic to fix that. I'll squash it later. That version doesn't need to be 2.8.12, does it? It needs only to be a version new enough to understand the generated content. The current value should be okay, no? Yes. It's not very pretty though for the final release to tell people that they should install '2.8.11.20130626 or later' instead of '2.8.12 or later', which is what we really intend to communicate. Thanks, Steve. -- 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] Please review CXXFeatures.cmake
Stephen Kelly wrote:
Stephen Kelly wrote:
I still think you should revisit my review mail on point 2 too.
Something that becomes possible when thinking about the above and target
properties is interface requirements.
I've implemented a prototype which has better API than your module.
In my concept:
* Applying the -std=c++11 flag is the responsibility of CMake, not the user.
* CMake determines the -std= flag to use (GCC 4.9 has -std=c++1y by now). It
won't add '-std=c++11 -std=c++14', but just '-std=c++14'
* Required compiler features are scoped to targets.
* Target properties are set, exported and transitively evaluated track the
compiler features required.
* Compiler requirements can be optional, in which case -D defines are
generated in the (PUBLIC) COMPILE_DEFINITIONS
* The -D defines are for scoping or replacement, depending on what the
feature calls for.
* Required compiler features are listed in the INTERFACE of exported
targets. CMake evaluates whether the compiler is capable of using the
IMPORTED targets it is supposed to use transitively, in a similar way to the
POSITION_INDEPENDENT_CODE feature.
* A new command target_compiler_feature is introduced with two signatures:
target_compiler_feature(target PUBLIC|PRIVATE
REQUIRED feature1 [feature2 ...])
target_compiler_feature(target PUBLIC|PRIVATE
OPTIONAL feature DEFINE define_name)
* Another non-target-scoped command could be introduced, similar to
target_compile_options - add_compile_options.
This is better in many noteworthy ways to the cxx11 topic in the stage.
Brad, do you have any response to any part of anything I wrote about that
topic?
Thanks,
Steve.
#include foo.h
A::A(int i, void *p)
: num(i), ptr(p)
{
}
A::A(const A other)
: num(other.num), ptr(other.ptr)
{
}
A::~A()
{
}
A A::operator=(const A other)
{
num = other.num;
ptr = other.ptr;
return *this;
}
B::B(int i, void *p)
: A(i, ptr)
{
}
#include utility
templatetypename T
struct Factory
{
// Variadic templates and macros required to use this library by design. Not guarded by any macro.
templatetypename... Args
static T Create(Args... args) { return T(std::forwardArgs(args)...); }
};
#define CREATE(TYPE, ...) Factory TYPE ::Create(__VA_ARGS__)
class A
{
templatetypename friend class Factory;
friend class B;
int num;
void *ptr;
A(int i, void *p = Foo_NULLPTR);
public:
#if Foo_RVALUE_REFS
inline A(A other) : num(other.num), ptr(other.ptr)
{
other.num = 0;
other.ptr = 0;
}
inline A operator=(A other)
{
std::swap(num, other.num);
std::swap(ptr, other.ptr);
return *this;
}
#endif
inline A(const A other);
inline A operator=(const A other);
virtual ~A();
virtual void doSomething() {}
virtual void doSomethingElse() {}
};
class B : public A
{
templatetypename friend class Factory;
B(int i, void *ptr = Foo_NULLPTR);
public:
void doSomething() Foo_OVERRIDE {}
void doSomethingElse() Foo_FINAL {}
};
#include foo.h
int main(int argc, char **argv)
{
auto a = CREATE(A, 47, new long);
auto b = CREATE(B, 42);
}
# FIXME: Encode this stuff into Modules/Compiler/*.cmake
if(CMAKE_CXX_COMPILER_ID STREQUAL GNU)
set(CMAKE_C_COMPILER_FEATURES)
if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.3)
list(APPEND CMAKE_C_COMPILER_FEATURES
variadic_macros
)
endif()
set(CMAKE_C99_STANDARD_COMPILE_OPTION -std=c99)
# FIXME: This feature listing is not complete.
set(CMAKE_CXX98_COMPILER_FEATURES)
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.3)
list(APPEND CMAKE_CXX98_COMPILER_FEATURES
member_templates
template_template_parameters
template_friends
)
endif()
set(CMAKE_CXX11_COMPILER_FEATURES)
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.3)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
decltype
rvalue_refs
static_assert
variadic_macros
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.4)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
auto_type
default_members
deleted_members
variadic_templates
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.6)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
nullptr
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
final
override
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9)
list(APPEND CMAKE_CXX14_COMPILER_FEATURES
# binary_literals
generalized_lambda_capture
return_type_deduction
)
endif()
set(CMAKE_CXX_COMPILER_FEATURES
binary_literals
${CMAKE_CXX98_COMPILER_FEATURES}
${CMAKE_CXX11_COMPILER_FEATURES}
${CMAKE_CXX14_COMPILER_FEATURES}
)
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11)
elseif(NOT CMAKE_CXX_COMPILER_VERSION
Re: [cmake-developers] CMake 2.8.12-rc1 Released
Robert Maynard wrote: Some of the notable changes in this release are: Some other things that I think are release-notes-worthy: - New PUBLIC PRIVATE and INTERFACE options for target_link_libraries - New ALIAS targets feature - Automatically process Headers directory of Frameworks on Apple as a usage requirement. (commit f5ca872e) Thanks, Steve. -- 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote: I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets I still don't know what for. Can it do anything I can't do by simply setting a variable to the aliased target(s) ? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7370/focus=7394 and double-colons-means-IMPORTED. I haven't followed closely. Does this mean creating a normal target which contains :: will be a cmake error ? Something like that, yes, with a policy. Thanks, Steve. -- 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] CMake 2.8.12-rc1 Released
Brad King wrote: On 08/22/2013 04:39 PM, Alexander Neundorf wrote: Beside that, I played around with it a bit. If 2.8.12 is required, it errors out, as documented. If I use 2.8.12 and require 2.8.11: [snip] So this seems to behave differently than in 2.8.11 even if 2.8.11 is required (and so the policy should be set accordingly). Steve? Fixed last week in the fix-OLD-CMP0021 topic. Thanks, Steve. -- 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] c++ feature detection and usage requirements
Brad King wrote:
On 08/15/2013 08:37 AM, Stephen Kelly wrote:
target_compiler_feature(target PUBLIC|PRIVATE
REQUIRED feature1 [feature2 ...])
target_compiler_feature(target PUBLIC|PRIVATE
OPTIONAL feature DEFINE define_name)
Doesn't this require the language (CXX) to be specified somewhere?
Perhaps the feature names should start with lang_ e.g. CXX_final.
I considered that, and I considered adding LANG lang to the command
signatures, and I considered naming the command with the language
(target_cxx_compiler_feature).
I didn't pick one, partly because it's a relatively minor detail we can
decide on after the larger issues below are resolved.
This is better in many noteworthy ways to the cxx11 topic in the stage.
Brad, do you have any response to any part of anything I wrote about that
topic?
The detection of features available for a given compiler and the
usage requirements to require/enable them are orthogonal issues
on the implementation side but may overlap in the CMake interface.
Yes. Even if we ignore the usage requirements angle, there are enough
reasons to not accept the currently proposed interface in the topic though.
I like your proposed target_compiler_feature feature for the latter.
Great.
As for detection, I like that Eike's solution will work without
hard-coding knowledge for every compiler. I also like hard-coding
the answers for known compilers whose id/version can be reliably
detected to avoid needless try_compile calls on every project.
Yes.
Furthermore, your argument about partial implementations of features
versus the documented later version introducing them is important.
Yes.
It is also nice to have it builtin to the platform information
modules for use with target_compiler_feature. I'd like to see a
solution that hard-codes the answers when known but also knows when
it does not know and can run a detection step.
Yes.
This will be tricky
because the platform files are too early to use try_compile so some
kind of on-demand check may be needed. Ideas?
That should be easy. Encode them into the platform files where known, and
implement target_compiler_feature to run a detection if
CMAKE_CXX_COMPILER_FEATURES is not set.
I think Eike's topic will be a fantastic reference for the test
case code
I agree that Tests/Module/FindCXXFeatures/CMakeLists.txt is a useful
reference. However, I don't think the interface in the topic should be
merged into master. We agree that target_compiler_feature is a better
interface, and hopefully Eike does too.
Eikes interface has some problems which I noted before here which make it
useless for libraries (or at least too incomplete to be useful) because the
result of the feature tests can't be used in public header files:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7715
Additionally, there is a 'cross platform trap' in the topic as it is
currently. Someone implementing a project on Windows using MSVC might write
this (assuming they were creating an executable, not a library because of
the above problem):
find_package(CXXFeatures)
if (CXXFeatures_class_override_final_FOUND)
add_definitions(-DGrantlee_FINAL=final)
endif()
It looks cross-platform, but it is not.
When they port the code to GCC, they need to add the ${CXX11_COMPILER_FLAGS}
somewhere (using the modern add_compile_options? No, using CMAKE_CXX_FLAGS
because it is _FLAGS).
My proposed interface does not have that problem because adding the compile
option for -std=c++11 (or -std=c++1y) is set internally.
As you said though, the detection code and the detection results encoded
into the tests are orthogonal to the interface issues. I think those parts
should be kept and refactored.
I don't think the topic should be merged as-is because of the problems with
the interface we know about so far. If you merge it and we also merge the
interface which we agree to be better, we'll have two competing interfaces.
and the expected results and will be useful for you to
write a more complete solution.
I'm sure Eike can do it too. Or at least get started with encoding the
detection results into platform files and refactoring the detection code out
of the find module so it can be used from the command.
I like the target_compiler_feature
syntax better than find_package(CXXFeatures), but something like the
latter may be needed to make CMake-time decisions based on available
features rather than waiting until preprocessing time.
Users could do the same as I suggest the target_compiler_feature does:
if (CMAKE_CXX_COMPILER_FEATURES)
list(FIND CMAKE_CXX_COMPILER_FEATURES final idx)
if(idx EQUAL -1)
set(HAVE_FINAL 0)
else()
set(HAVE_FINAL 1)
endif()
else()
include(DetectCompilerFeature)
detect_compiler_feature(final HAVE_FINAL)
endif()
if(HAVE_FINAL)
# ...
endif()
Or, even better,
include(DetectCompilerFeature)
# Checks
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
On 08/27/2013 05:56 PM, Stephen Kelly wrote:
and the expected results and will be useful for you to
write a more complete solution.
I'm sure Eike can do it too. Or at least get started with encoding the
detection results into platform files and refactoring the detection code
out of the find module so it can be used from the command.
Can you propose a specific representation of this information in the
platform
files? If you get one feature done then perhaps Eike can fill in the rest
of the details using the knowledge he's gained from his work so far.
I propose refactoring the information into lists similar to what I did here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7746
I've pushed a compiler_features branch to my clone with a slightly more
advanced implementation.
I also still think there should be a way for CMake to write a header file
In the past we've avoided providing any kind of library with CMake, even a
header-only one. GenerateExportHeader and FortranCInterface are precedent
for generating headers that abstract platform-specific details. However,
they only provide preprocessor definitions, not actual code.
The header file would have the preprocessor tests and version checks for
the known compilers. That is, the generated header file would be the same
on all platforms, and would look something like qcompilerdetection.h, but
with a customizable prefix for the macros.
[snip]
For is_convertible etc, there is a BSD licensed type_traits compatibility
header here, which Qt 5 uses too and which could be distributed with
CMake:
I'm a bit hesitant to provide such a library header but the knowledge it
encodes could reduce a lot of duplication across projects.
I understand. With this 'C++11' discussion, I think of it more as a request
for CMake to make it easier to 'normalize compiler features' by somehow
using a define for things like FINAL and OVERRIDE and others, as the Qt and
Boost (and libcxx) systems do.
Of course, the compiler features need to be well defined in name and meaning
in CMake documentation somewhere.
Thinking about it like that led me to think of member_templates as a
compiler feature (common now, but MSVC6 didn't support them IIRC). The same
thought process leads me to think convenience for creating a header is a
good idea, for normalization purposes. As you said, there is some precedent.
Similarly,
I've been tempted to provide KWIML in CMake distributions:
http://cmake.org/gitweb?p=cmake.git;a=tree;f=Utilities/KWIML;hb=v2.8.11.2
to provide abstracted C fundamental type information macros and eliminate
a large chunk of check_type_size calls.
At least the @KWIML@_INT_INT#_C(c) is part of a 'normalization'. Qt provides
qint32, qint64 etc for the same purpose.
So, at least parts of KWIML should fit into this discussion too, as I see
it.
In both cases I'm hesitant for
reasons of maintenance difficulty and commitment to backward compatibility
in the API. If instead projects distribute their own copies then we have
the option of changing the API and it is up to them to deal with it when
updating.
Yes. That's what I propose too.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
)
install(FILES
${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
${CMAKE_CURRENT_BINARY_DIR}/grantlee_export.h
DESTINATION include/
)
Perhaps this concern could be mitigated by the fact that we're generating
the headers driven by calls to a module function. If the calls specified
some kind of interface version then we would have a path for changing
things.
Yes, versioning is a good idea to think about. I haven't thought about that
yet.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
VERSION 3
)
perhaps?
Thanks,
Steve.
--
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 --help-concept
Hi there, There are a few concepts in CMake whose documentation is dotted around various places, but without a single location to learn about the concept itself, how it should be used, and what needs to be kept in mind when using it. A new documentation section for concepts could be introduced. For example, * cmake --help-concept usage_requirements Describe the INTERFACE_ properties, that the requirements can be exported, commands used to populate the properties, tll to use them, and overriding the order with target_include_directories(foo PRIVATE $TARGET_PROPERTY:bar,INCLUDE_DIRECTORIES) etc. * cmake --help-concept generator_expressions Describe how they are evaluated (and should be read), where they are needed and what they're useful for (config-specific things mostly), file(GENERATE) etc. * cmake --help-concept imported_targets How to export targets, creating a FooConfig.cmake and what should be in it etc. * cmake --help-concept compiler_features List possible compiler_feature names and meanings (eg, the final compiler_feature means sealed on old MSVC). What do you think? Thanks, Steve. -- 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] INTERFACE_LIBRARY target type
Hi there, I've rebased and pushed the INTERFACE_LIBRARY-target-type branch to my clone again. I'd like to get this one in to the next release soon after it opens for features, but there are still a few things to discuss about how it should work. Relevant previous threads: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6691 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5320 1) We already have ALIAS targets, which leaves INTERFACE_LIBRARY to cover the uses cases of add_library(iface INTERFACE) target_link_libraries(iface INTERFACE bing sing) target_link_libraries(foo INTERFACE bar iface bat) and add_library(iface INTERFACE) target_link_libraries(iface INTERFACE bing sing) target_link_libraries(foo INTERFACE bar $TARGET_PROPERTY:iface,INTERFACE_LINK_LIBRARIES bat ) I think that's fine. 2) In my branch, the 'old' (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_CONFIG)? are always ignored for INTERFACE_LIBRARY types, for simplicity like the above, and always being able to rely on the INTERFACE_LINK_LIBRARIES property for them. 3) I have left a TODO note in cmLocalGenerator.cxx about the return value from GetRealDependency. 4) The target_* commands always need to be invoked with an explicit INTERFACE option. 5) The INTERFACE_LIBRARY can be installed and exported, resulting in add_library(Foo::iface INTERFACE IMPORTED) # ... In my branch, the versions are a bit messed up in the install(EXPORT) code, due to what's currently in master. That will be cleaned later. 6) When we get transitive INTERFACE_SOURCES, it will be possible to 'link to' OBJECT_LIBRARYs: add_library(obj OBJECT foo.cpp) add_library(obj_iface INTERFACE) set_property(TARGET obj_iface PROPERTY INTERFACE_SOURCES $TARGET_OBJECTS:obj ) add_executable(user main.cpp) target_link_libraries(user obj_iface) So, it might make sense to revisit whether it is allowed to link to OBJECT_LIBRARYs. Either way, the obj_iface can't be exported in this case, because the dependent obj library can't be exported. 7) I've only implemented the support for this target type in the Makefile generator so far. I can also do the Ninja one after all of the details about how it works are sorted out. Can someone else implement the VS and Xcode support? I'm too unfamiliar with those generators. 8) I made it possible to use make iface to build the *dependencies* of iface. The special /requires /depends and /build sub-targets are not generated for INTERFACE_LIBRARY targets. 9) INTERFACE_LIBRARY targets are always effectively EXCLUDE_FROM_ALL because they have no direct outputs. Is there anything I'm missing here? Thanks, Steve. -- 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 --help-concept
Alexander Neundorf wrote: The consensus was that it's a good idea, but it needs better linking within the documentation: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5924 Too bad about the bikeshedding. The point is not about de-duplication (though that can also be solved with this) or getting caught up in markup or how to reference other sections. The point is to have 'entry point' docs for the essential concepts in cmake. We should add these concept sections to the docs and we can add 'See the documentation of the generator_expression concept' where it makes sense. We should not change or extend the markup or make adding these concept sections dependent on choosing and implementing a new markup for docs. Thanks, Steve. -- 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] INTERFACE_LIBRARY target type
Stephen Kelly wrote: Hi there, I've rebased and pushed the INTERFACE_LIBRARY-target-type branch to my clone again. See also proof of concept here: https://github.com/purpleKarrot/BoostCMake/pull/1 which is the ongoing work to use CMake for boost using ALIAS targets, INTERFACE targets, EXPORT_NAME, usage requirements etc. It allows this to 'just work': cmake_minimum_required(VERSION 2.8.11) # 2.8.13 project(Test) find_package(BoostAny REQUIRED) add_executable(someexe main.cpp) target_link_libraries(someexe boost::any) For boost, a few more interesting INTERFACE features will be needed eventually, but one step at a time... :) Thanks, Steve. -- 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] c++ feature detection and usage requirements
Brad King wrote:
Yes, versioning is a good idea to think about.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
VERSION 3
)
This could help somewhat because we could change what is produced
by a newer version while still knowing how to generate the old
version. The version argument must be required.
Ok, I see what you mean.
Another option would be not to have the VERSION in the signature, but always
use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
The content generated depends only on the features of the cmake binary being
run, so it relieves users of the need to additionally maintain the VERSION
here and figure out how that maps to their minimum cmake version.
Rather than a single versioned header we should also consider
asking the caller to list the information and features needed.
That way a project can expose a header without more information
than they want to support.
Yes, good idea.
Thanks,
Steve.
--
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_link_libraries, IMPORTED targets and SYSTEM includes
Stephen Kelly steveire@... writes: Matthew Woehlke wrote: Perhaps that is a misreading on my part, but I was getting the impression this change would make it so that imported targets can only ever be SYSTEM. I didn't really make that clear as the discussion developed, but yes, I think it makes sense to allow treating the include directories as non-system somehow, even if not by default. I've pushed the IMPORTED-target-SYSTEM-includes topic to my clone for review. It introduces a policy-controlled default handling of INTERFACE_INCLUDE_DIRECTORIES from IMPORTED targets as SYSTEM. It also introduces a default-initialized target property to get the opposite behavior in the cases where that is wanted. It also introduces a SYSTEM option to target_link_libraries because I'd already written the patch, but I'm not certain that's needed anymore. Thanks, Steve. -- 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] c++ feature detection and usage requirements
Brad King wrote:
On 08/29/2013 11:14 AM, Stephen Kelly wrote:
Another option would be not to have the VERSION in the signature, but
always use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
The content generated depends only on the features of the cmake binary
being run, so it relieves users of the need to additionally maintain the
VERSION here and figure out how that maps to their minimum cmake version.
A project may wish to update to a newer required CMake version for some
other feature but is not ready to port their header generation. We
could define the versions w.r.t. the CMake version and make VERSION
optional. If not present use CMAKE_MINIMUM_VERSION_REQUIRED. If
present then fail if VERSION is newer than CMAKE_MINIMUM_VERSION_REQUIRED.
I put an untested pseudo-code version of this in my compiler_features
branch. It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake. Otherwise I
wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in Modules/CompilerFeatures/${ID}-${LANG}.cmake
instead?
We also need a plan to phase out support for ancient versions in the
future.
Any ideas on how to do that?
Thanks,
Steve.
--
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] c++ feature detection and usage requirements
Brad King wrote:
On 08/30/2013 08:02 AM, Stephen Kelly wrote:
It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake.
Otherwise I wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in
Modules/CompilerFeatures/${ID}-${LANG}.cmake instead?
Why do you need to check features of a compiler not currently enabled?
Without being enabled we don't even know what version of the other
compiler to check.
CMake has the information for all compilers, and the idea was to use that
information to generate a header for use with all of them.
Stephen Kelly wrote:
The header file would have the preprocessor tests and version checks for
the known compilers. That is, the generated header file would be the same
on all platforms, and would look something like qcompilerdetection.h, but
with a customizable prefix for the macros.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7655
However, thinking about it again, I think you're right that that is not
necessary. The built package and generated header is compiler/platform
specific anyway, unlike qcompilerdetection.h, which is a source file
identical in the packages for all platforms.
I thought the idea was to specify in target_compiler_features the
features needed so they would be published in the target interface.
Then whatever compiler is used can have its feature set tested against
the requirements. This would work both in-project and in consumers, no?
Yes, I went on something of a tangent here.
Thanks,
Steve.
--
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] c++ feature detection and usage requirements
Brad King wrote: BTW, I think a better name may be language features rather than compiler features because we are declaring features of language versions and variants, not of the compilers. I don't agree with that. We are enumerating/introspecting the features of the compiler. The fact that the compiler is following a standard for its features is/should be irrelevant to the interface, and to the list of features. I've seen a few projects debating the useless question of 'Can we use C++11 now?', which eventually or quickly turns into the useful question of 'What features can we use from our compiler, given our minimum requirements?'. That's actually the same question they've always had to ask. They didn't consider questions like 'can we use C++98 now?', but 'can we use member templates now?'. The answer often being 'Yes, if we don't support MSVC6 anymore - it does not have that feature'. Such a view also justifies using the non-language-standard MSVC 'sealed' keyword in place of 'final' for 'the final feature', as the features are compatible. There may be other cases of such compatibility from non-standard compiler- provided features (which influenced the standard presumably). It is only in the implementation that we need to deal with compiler support for the features. Contrarily I say, it is only in the implementation that we need to consider the language-standard support for the features, because that is where the implementation needs to know (for some compilers) the standard the feature was introduced in, in order to pass the correct -std= argument. The language standard does not appear in the interface I've proposed, because it is irrelevant. The only relevant information is the minimum compiler requirements of the project. Thanks, Steve. -- 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] Getting a list of files to install and their destination
Hi there,
On the QtCreator list recently there was a discussion about installing
projects which use cmake to device targets:
http://thread.gmane.org/gmane.comp.lib.qt.creator/8995
The want to transfer files without invoking make install. I think the only
reason for that is because it could be a lengthy operation (with cmake I'm
not so sure - I think cmake doesn't reinstall something that is not
changed).
Additionally, my several points that installation may be necessary were not
addressed:
http://thread.gmane.org/gmane.comp.lib.qt.creator/8995/focus=8997
http://thread.gmane.org/gmane.comp.lib.qt.creator/8995/focus=9008
The solution they seem to want to require is maintaining the list of files
to install in parallel to the install() commands.
I was wondering if there was some way that cmake could generate a list of
files and destination for them with a built-in make-target? I guess the
limitation of that is that install(SOURCE) and install(CODE) can do
arbitrary things. I've never used them, but presumably they would use
file(COPY) to put files in the installation location using
${CMAKE_INSTALL_PREFIX} ? That probably makes the built-in make-target to
generate a list of files and destinations a non-starter.
Am I right in saying that even for remote deployment, cmake will not
transfer files which are not changed? And therefore the worry about that
from the creator folks is unfounded? And the only solution that actually
works for them is installing to a tmp location, given the possible existence
of install(SCRIPT) and install(CODE)?
Thanks,
Steve.
--
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] Targets for FindGTK2.cmake
Daniele E. Domenichelli wrote:
Hello Stephen,
Sorry for the delay, but I was on holiday...
On 14/08/13 15:07, Stephen Kelly wrote:
Daniele E. Domenichelli wrote:
I did a few more tests, and it looks like that, at least on my system
and on windows, FREETYPE_LIBRARIES are not required, they are linked to
some other libraries (i.e. cairo) but they don't need to be linked
explicitly
On the other hand, the FREETYPE_INCLUDE_DIR is required, because some
public header includes freetype headers.
Can you confirm that the things used in those cases from the headers are
only defines, enum values, inline functions etc, and not anything that
becomes part of the ABI (such as inheriting from a type etc)? Or,
otherwise, can you determine why the freetype header is in the public
headers?
I think I can confirm it... at least on the versions I have on my system
(debian testing) and on windows (gtkmm installer), the only file
included in GTK2 ( related libraries) include files seems to be
ft2build.h that includes freetype/config/ftheader.h that contains only
macros + one more include, but only when freetype is built. Therefore
I'm quite sure that it is not necessary to link libfreetype explicitly.
Ok, great. Thanks for checking that.
This is another build machine on the dashboard (SunOS5.9-CC) where
FindFreetype causes issues.
http://open.cdash.org/testDetails.php?test=206968805build=3019758
I'm quite sure now that just not linking FREETYPE_LIBRARY explicitly is
the way to fix this on all the systems... Am I allowed to make a commit
and eventually revert it in order to test on the build machines if it
works on all systems?
Yes, sometimes there is no other way to get that kind of feedback about
problems reported by the dashboard. Another option of debugging dashboard
problems is asking the operator of the machine to test something.
Generally I think making commits in order to test behavior on a particular
machine is ok if it doesn't cause general disruption on all dashboards
(though I've been guilty of doing that before :) ). Then again, they're not
my machines/hardware :).
On window using gtkmm installer, find_package(Freetype) freetype is not
found, FREETYPE_FOUND is FALSE, FREETYPE_LIBRARY is
FREETYPE_LIBRARY-NOTFOUND, but FREETYPE_INCLUDE_DIR is set correctly
(the headers are installed, but the .lib file is missing)
I'm not sure if this is a bug in FindFreetype (FREETYPE_INCLUDE_DIR
should be unset if freetype was not found?)
Perhaps. If so, maybe that's something FPHSA should do? Seems like a
separate topic though.
Do you mean that the windows gtk installer does not install the .lib file
at all, but does install the include files (because it only uses
defines/enums and doesn't need to link to the thing?)?
It installs the headers and the .dll, but not the .lib. Therefore
libraries and executables already linked with, will find the required
.dll when they are executed, but it is impossible to link new ones.
Ok.
The includes used by GTK2 only have defines but the other freetype
include files define methods, etc. though, so if one of those is
included directly, the build will fail to find the symbols.
I think this is ok. Downstreams will have to link to freetype directly if
they want to use it directly, and nothing newly-breaks as that has always
been the case.
Therefore I believe that I should just look for the 2 include files
required by GTK2 only. FindFreetype already defines
FREETYPE_INCLUDE_DIR_ft2build and FREETYPE_INCLUDE_DIR_freetype2 that
look exactly for these files, and FREETYPE_INCLUDE_DIRS is defined as
set(FREETYPE_INCLUDE_DIRS
${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2})
but I wonder if it is correct to leave this variable set, even if
FREETYPE_FOUND is FALSE.
Something to put to a wider audience in a separate thread I think. I can see
how such behavior could be considered backward incompatible (though the
_FOUND variable should technically be checked).
Anyway I believe that instead of checking for FREETYPE_FOUND, I could
check and use FREETYPE_INCLUDE_DIR_ft2build and
FREETYPE_INCLUDE_DIR_freetype2 directly, and that FREETYPE_INCLUDE_DIRS
should be unset if FREETYPE_FOUND is false
Seems fine to me.
Btw, was there any effort to get the gtk upstream to produce cmake config
files with IMPORTED targets?
Not that I know about, and almost for sure not for GTK2 since afaik the
development is now focused on GTK3
Ok. Thanks for your thorough research on this!
Steve.
--
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] INTERFACE_LIBRARY target type
Brad King wrote: 3) I have left a TODO note in cmLocalGenerator.cxx about the return value from GetRealDependency. Callers of GetRealDependency are looking for a file-level dependency. Targets like OBJECT_LIBRARY and INTERFACE_LIBRARY have no real file on which to depend. The OBJECT_LIBRARY comment This was listed to get the target-level dependency is talking about ordering dependencies among logical targets. Ok, I've changed the patch to add a similar comment for INTERFACE_LIBRARY types. 7) I've only implemented the support for this target type in the Makefile generator so far. I can also do the Ninja one after all of the details about how it works are sorted out. Can someone else implement the VS and Xcode support? I'm too unfamiliar with those generators. Do you mean support for make iface in the other generators? Yes. Something similar to what is changed in the makefile generator in the first patch 'Add the INTERFACE library type.' is likely needed in other generators too. 9) INTERFACE_LIBRARY targets are always effectively EXCLUDE_FROM_ALL because they have no direct outputs. ...but they do have dependencies on other targets, as built by make iface. If a given directory contains nothing but an interface target that depends on real targets from other directories, shouldn't typing make in that directory bring everything up to date to use the interface? Good point. I'll look into that a bit more. Thanks, Steve. -- 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_link_libraries, IMPORTED targets and SYSTEM includes
Brad King wrote: On 08/30/2013 06:49 AM, Stephen Kelly wrote: I've pushed the IMPORTED-target-SYSTEM-includes topic to my clone for review. It introduces a policy-controlled default handling of INTERFACE_INCLUDE_DIRECTORIES from IMPORTED targets as SYSTEM. It also introduces a default-initialized target property to get the opposite behavior in the cases where that is wanted. The wording in the warning is a bit confusing: + property. This will not cause the contents of the property + to be treated as system includes.; As someone used to the old behavior I would read this and think Why are you warning me that nothing is changing?. Ok, I'll see if I can do better later. BTW, the policy number jumps to CMP0027. This should be renumbered if no other policies are introduced first. Yes. The export-policy branch in next introduces CMP0024. The target-LOCATION-policy branch in my clone introduces CMP0025. I can't merge that to next until export-policy is in or as good as in. Otherwise I might have to change export-policy and have conflicts I'd prefer to avoid. The double-colon-is-imported branch in my clone introduces CMP0026. I didn't complete that one yet because the two branches above need to go in serially first. I also haven't added tests to IMPORTED-target-SYSTEM-includes yet because it's less to re-number if things change between now and when I can merge it to next. OTOH, this policy will trigger on every target that links to libraries providing usage requirements. At most this is a difference between -I and -isystem which affects compilation only in incidental ways. Yes. Do we really need a policy? Without one, projects will magically start building with fewer unnecessary warnings. I'm fine with not controlling this with a policy. An abundance of caution led me to introduce one for it, but I'll happily remove it. Thanks, Steve. -- 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] INTERFACE_LIBRARY target type
Stephen Kelly wrote: 7) I've only implemented the support for this target type in the Makefile generator so far. I can also do the Ninja one after all of the details about how it works are sorted out. Can someone else implement the VS and Xcode support? I'm too unfamiliar with those generators. Do you mean support for make iface in the other generators? Yes. Something similar to what is changed in the makefile generator in the first patch 'Add the INTERFACE library type.' is likely needed in other generators too. I've done this part and merged into next for testing. I split off the 'make iface' stuff into a separate gitorious/INTERFACE_LIBRARY-build-targets topic in my clone. I suspect the generator-specific parts of that will be more-involved. Thanks, Steve. -- 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] Warnings with CMake 2.8.12-rc3 driving dashboards
Brad King wrote: Can you please teach it to print out the value of each of the two properties so we have some hint about what is different? I pushed print-CMP0022-content-conflict and merged it to next. Thanks, Steve. -- 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] Interface library test failures with VS60
Hi there, http://open.cdash.org/viewTest.php?onlyfailedbuildid=3027577 shows some failures which I can't reproduce as I don't have VS6. Can you help finding/fixing the problem? Thanks, Steve. -- 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] Interface library test failures with VS60
Brad King wrote: On 09/13/2013 07:21 AM, Stephen Kelly wrote: http://open.cdash.org/viewTest.php?onlyfailedbuildid=3027577 shows some failures which I can't reproduce as I don't have VS6. Can you help finding/fixing the problem? Not enough of the VS generators is turned off for interface targets and the VS 6 generator crashes on them. Here is a fix to totally drop interface targets from the generation: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52ed980d Terrific, thanks. Most of this change will need to be reverted when support for the equivalent of make iface is added to the VS generators, but for now I'm not sure how that should work anyway. This matches the current state of the other generators anyway. I don't mind delaying that part completely for now. Thanks, Steve. -- 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 --help-concept
Brad King wrote: On 08/28/2013 03:28 PM, Stephen Kelly wrote: We should add these concept sections to the docs and we can add 'See the documentation of the generator_expression concept' where it makes sense. We should not change or extend the markup or make adding these concept sections dependent on choosing and implementing a new markup for docs. The --help-concept proposal is for a specific new section rather than general infrastructure for adding sections. It can be one man page that has an item for each concept, just like the command help has an item for each command. This can be done independent of other changes discussed in the thread Alex linked. I've pushed the concept-help branch to next for review, along with one documentation item on policies. Once the details are worked out and merged, I can write some more, and Alex may want to too. Thanks, Steve. -- 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 --help-concept
Alexander Neundorf wrote: On Saturday 14 September 2013, Stephen Kelly wrote: Brad King wrote: On 08/28/2013 03:28 PM, Stephen Kelly wrote: We should add these concept sections to the docs and we can add 'See the documentation of the generator_expression concept' where it makes sense. We should not change or extend the markup or make adding these concept sections dependent on choosing and implementing a new markup for docs. The --help-concept proposal is for a specific new section rather than general infrastructure for adding sections. It can be one man page that has an item for each concept, just like the command help has an item for each command. This can be done independent of other changes discussed in the thread Alex linked. I've pushed the concept-help branch to next for review, along with one documentation item on policies. Once the details are worked out and merged, I can write some more, and Alex may want to too. Would e.g. the list of supported languages or toolchains be a candidate for that concepts section ? Or should the languages be documented in the enable_language() documentation ? I'd say that if there's a language concept section, it would say that the project command can be used to enable languages, and that it enables C and CXX by default. It would also say that enable_language can be used to enable languages. It would also list the language specfic variables that can be set by the user. If 3rd party language support is a supported use-case of cmake (I'm not sure), it would describe how to add support for a language. It could also list the languages built-in to CMake, but it would be more than just a list. It should be a starting point to other commands and variables relevant to language support in CMake. Thanks, Steve. -- 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] AUTOUIC and AUTORCC for Qt
Hi there, I've pushed the Qt-auto-generators topic to my clone. https://gitorious.org/cmake/steveires-cmake/commits/Qt-auto-generators It is a proof of concept for features similar to AUTOMOC, but for invoking the uic and rcc tools shipped with Qt. I'd like to generalize the AUTOMOC feature to be able to remove more of the need to use macros with Qt for ui files and rcc files. Any comments? Thanks, Steve. -- 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 type for static plugins?
Hello, In CMake, the MODULE_LIBRARY type is quite like a shared library which is not linked to. In Qt, there is a concept of a static plugin. This is essentially just a static library, but there is buildsystem awareness of the difference. When building a static library using Qt, the QT_STATICPLUGIN preprocessor macro must be defined: http://doc-snapshot.qt-project.org/qt5-stable/qtcore/plugins-howto.html#static-plugins This affects the compilation of moc generated files (In Qt 5 plugin information is generated by moc). If CMake had a STATIC_MODULE library type, I would be able to add: $$STREQUAL:$TARGET_PROPERTY:TYPE,STATIC_MODULE:QT_STATICPLUGIN to the INTERFACE_COMPILE_DEFINITIONS of Qt5::Core, and all consumers wishing to create a static library would use add_library(mystatic_library STATIC_MODULE foo.cpp) target_link_libraries(mystatic_library Qt5::Core) and automatically get the correct definition set. Any comments on adding a new STATIC_MODULE type to CMake? Thanks, Steve. -- 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 type for static plugins?
Brad King wrote: On 09/20/2013 08:14 AM, Stephen Kelly wrote: Any comments on adding a new STATIC_MODULE type to CMake? Other than the TYPE being a different name, how would CMake treat this target type differently? In the case of Qt, I don't see much else relevantly different between static libraries and static plugins. So the answer is, 'probably nothing'. The other thing Qt does with static plugins is generate a file with Q_IMPORT_PLUGIN calls. That part relates to the INTERFACE_SOURCES concept: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7082 I could imagine it being useful for any project which can build shared or static and has a plugin interface with a similar need for a PP define though. Thanks, Steve. -- 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 type for static plugins?
Brad King wrote: So the answer is, 'probably nothing'. In that case I do not think we can justify a special CMake target type for it. All the special cases for STATIC_LIBRARY targets will have to be updated to also account for the new type with no difference in logic. Another alternative would be for add_library(myplugin STATIC_MODULE foo.cpp) be exactly equivalent to add_library(myplugin STATIC foo.cpp) set_property(TARGET myplugin PROPERTY STATICPLUGIN 1) and document the STATICPLUGIN target property. Then I can use that in the Qt5::Core INTERFACE_COMPILE_DEFINITIONS, and no handling of static libraries in CMake would need to be extended for the new type. The cmAddLibraryCommand would set the property. Thanks, Steve. -- 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 type for static plugins?
Brad King wrote:
On 09/20/2013 01:40 PM, Stephen Kelly wrote:
macro(qt_add_plugin name type)
if (${type} STREQUAL STATIC OR ${type} STREQUAL MODULE)
set(_type ${type})
set(args ${ARGN})
else()
set(_type MODULE)
set(args ${type} ${ARGN})
endif()
add_library(${name} ${_type} ${ARGN})
s/ARGN/args/ ?
Yes.
if (_type STREQUAL STATIC)
set_target_properties(${name} PROPERTIES
PLUGIN 1
# Not sure if this is a Qt/KDE convention:
PREFIX
)
endif()
endmacro()
Don't you want an empty prefix for MODULE too?
Yes. I was assuming the existence of
set(CMAKE_SHARED_MODULE_PREFIX )
Actually the empty prefix doesn't seem to be a Qt convention, only a KDE
one:
stephen@hal:~/dev/build/qtbase/qtbase$ l plugins/imageformats/
libqgif.so* libqico.so* libqjpeg.so*
So it wouldn't belong in a qt_add_plugin macro anyway, and kde would need
its own wrapper macro to set the prefix.
Those layers of wrapper macros are exactly what I'm aiming to avoid with
modern CMake patterns, so I will not add the qt_add_plugin macro to Qt 5.
Thanks,
Steve.
--
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] Private link depends can be public package depends
Hello,
Consider this:
add_library(foo SHARED ...)
add_library(bar SHARED ...)
target_link_libraries(foo LINK_PRIVATE bar)
install(TARGETS foo EXPORT FooTargets ...)
install(TARGETS bar EXPORT BarTargets ...)
install(EXPORT FooTargets ...)
install(EXPORT BarTargets ...)
This is very common in the KDE Frameworks buildsystem currently. The targets
are in a single monolithic buildsystem (currently), and are exported to
different export sets.
Because foo contains
IMPORTED_LINK_DEPENDENT_LIBRARIES bar
the 'bar' target is part of the missing target check code in
cmExportFileGenerator::GenerateMissingTargetsCheckCode.
If bar was part of the same export set as foo, or if bar was an imported
target, that would not be the case. However, then the correct -rpath-link
entry may not be created for 'bar'. This has previously been considered a
minor issue. Downstream can add a find_package for bar if it is in an
unusual location.
How should this be resolved? Should the contents of
IMPORTED_LINK_DEPENDENT_LIBRARIES be public package dependencies always? Or
should they not be added to the public package dependencies as they are now
in the above case?
My preference is the latter. The patch is quite simple:
diff --git a/Source/cmExportFileGenerator.cxx
b/Source/cmExportFileGenerator.cxx
index ef336ea..b67cc46 100644
--- a/Source/cmExportFileGenerator.cxx
+++ b/Source/cmExportFileGenerator.cxx
@@ -736,9 +736,11 @@ cmExportFileGenerator
IMPORTED_LINK_INTERFACE_LANGUAGES,
iface-Languages, properties,
missingTargets);
+std::vectorstd::string dummy;
+
this-SetImportLinkProperty(suffix, target,
IMPORTED_LINK_DEPENDENT_LIBRARIES,
-iface-SharedDeps, properties,
missingTargets);
+iface-SharedDeps, properties, dummy);
if(iface-Multiplicity 0)
{
std::string prop = IMPORTED_LINK_INTERFACE_MULTIPLICITY;
Thanks,
Steve.
--
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] C++11 and target_compiler_feature proposal
Brad King wrote:
Steve, please explain your proposal in more detail. How does the list of
requested features get mapped to the proper -std=cxx11 or equivalent flag?
In my branch that is determined by which list the feature appears in. Eg,
from GNU-CXX.cmake:
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
final
override
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9)
list(APPEND CMAKE_CXX14_COMPILER_FEATURES
generalized_lambda_capture
return_type_deduction
)
endif()
Then, in the implementation of target_compiler_feature,
list(FIND CMAKE_CXX11_COMPILER_FEATURES ${FEATURE_NAME} needs11)
list(FIND CMAKE_CXX14_COMPILER_FEATURES ${FEATURE_NAME} needs14)
list(FIND CMAKE_CXX17_COMPILER_FEATURES ${FEATURE_NAME} needs17)
if(NOT needs17 EQUAL -1)
set(standard 17)
elseif(NOT needs14 EQUAL -1)
set(standard 14)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD ${standard})
Then, in cmLocalGenerator:
const char *standard = target-GetProperty(CXX_STANDARD);
std::string compile_option =
CMAKE_CXX + std::string(standard) + _STANDARD_COMPILE_OPTION;
if (const char *opt =
target-GetMakefile()-GetDefinition(compile_option.c_str()))
{
this-AppendFlags(flags, opt);
}
This is where I have an open question in the branch:
# TODO: Gnu extensions supported by -std=gnu++98 ?
# And others.
http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/C-Dialect-Options.html#C-Dialect-Options
# TODO: Maybe instead we should define like this:
#
# set(CMAKE_C_COMPILE_OPTIONS_STD -std=)
# set(CMAKE_CXX_COMPILE_OPTIONS_STD -std=)
#
# so that the CXX_STANDARD target property can contain the argument string
# (including possibly extensions).
# That might call for some kind of mapping though because XL uses different
# values (eg extended0x)
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9
# AND VERSION_LESS 4.11 # Speculative
)
set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++1y)
endif()
# if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.11) # Speculative
# set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++14)
# endif()
--
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] C++11 and target_compiler_feature proposal
Brad King wrote: Steve, Eike, Now that 2.8.12 is tagged I'd like to revive the work to support C++11 features. I met Eike in person today at Qt DevDays and talked about this topic a bit. The way forward is for me to get the infrastructure in place by cleaning up my branch. I'll aim for handling a single feature. Then Eike will help with encoding the information in the Modules files and the fallback compile tests. We'll initially defer the concept of generating a header file with defines/MyStaticAssert etc. I'll try to get a reviewable and first-feature-complete infrastructure branch together soon. Thanks, Steve. -- 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] Processing export() at generate-time
Hello, I pushed a export-at-generate-time topic to my clone. It changes the behavior of export() to be executed at generate-time by default, unless the result is include()d (policy CMP0024). This is needed to be able to have multiple dependent export sets in the build directory. I make use of that in my clone of the boost-cmake repo: https://github.com/steveire/BoostCMake/commits/master Any comments on this? Can I merge it to next? Thanks, Steve. -- 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] Some doc generation failing in target-LOCATION-policy topic
Brad King wrote: On 10/10/2013 12:57 PM, Brad King wrote: On 10/10/2013 12:09 PM, Stephen Kelly wrote: For example: http://open.cdash.org/viewBuildError.php?buildid=3055146 It seems that machine is not processing the $TARGET_FILE genex. Any idea why? That requires CMake = 2.8.4 to build. Currently our min req version is 2.8.2. I've updated Kitware's dashboard machines to be = 2.8.4 so the code should work, but the top-level CMakeLists.txt still needs to be told about 2.8.4 as the minimum version required. Thanks! I've pushed a topic to bump that now. Steve. -- 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] Processing export() at generate-time
Brad King wrote: On 10/10/2013 11:10 AM, Stephen Kelly wrote: I pushed a export-at-generate-time topic to my clone. It changes the behavior of export() to be executed at generate-time by default, unless the result is include()d (policy CMP0024). This is needed to be able to have multiple dependent export sets in the build directory. I haven't reviewed every hunk in detail but overall it looks good. It will be nice to have a feature to sell the need for CMP0024 in the same release that introduces the policy. To be clear, the topic changes export() to be executed at configure-time, independent of the policy. Only the OLD policy behavior only forces the file to be generated at configure-time instead. I've pushed the topic for dashboard testing. Thanks, Steve. -- 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] C++11 and target_compiler_feature proposal
Brad King wrote:
On 10/09/2013 10:44 AM, Stephen Kelly wrote:
if(NOT needs17 EQUAL -1)
set(standard 17)
elseif(NOT needs14 EQUAL -1)
set(standard 14)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD ${standard})
This assumes a linear ordering among standards, which is true for the
actual standards, but may not be true for the compiler feature levels.
For example, the GNU compiler has a gnu variant branching off from
each standard level.
Right, it is not really linear. One of my dependencies might require some
extension feature like 'gnu_template_instantiation' feature, which we'd list
as being a -std=gnu++98 feature.
http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html#Template-Instantiation
Another dependency might require variadic_templates, which is -std=c++11.
So, our calculation should result in -std=gnu++11, assuming extensions are
either consistently available between standard version specifications or
subsumed by more-recent standards.
Are any other compilers as 'interesting' or have extensions like that?
Interestingly, clang supports rvalue references in c++98 mode as an
extension, but GCC does not:
http://clang.llvm.org/docs/LanguageExtensions.html
stephen@hal:~/dev/src/playground/cpp{master}$ clang++ main.cpp
main.cpp:71:18: warning: rvalue references are a C++11 extension [-Wc++11-
extensions]
int function(int i)
^
1 warning generated.
stephen@hal:~/dev/src/playground/cpp{master}$ clang++ -std=c++98 main.cpp
main.cpp:71:18: warning: rvalue references are a C++11 extension [-Wc++11-
extensions]
int function(int i)
^
1 warning generated.
stephen@hal:~/dev/src/playground/cpp{master}$ clang++ -std=gnu++98 main.cpp
main.cpp:71:18: warning: rvalue references are a C++11 extension [-Wc++11-
extensions]
int function(int i)
^
1 warning generated.
stephen@hal:~/dev/src/playground/cpp{master}$ g++ -std=gnu++98 main.cpp
main.cpp:71:18: error: expected ‘,’ or ‘...’ before ‘’ token
main.cpp: In function ‘int function(int)’:
main.cpp:73:10: error: ‘i’ was not declared in this scope
This means that if(CLANG), we could list rvalue references as a c++98
feature, and specify -Wno-c++11-extensions as the flag. However, I don't
think that's a good idea. I just mention it for completeness. Similarly,
both clang and GCC accept variadic templates by default, also with a
warning. For anything that warns, I suggest we consider it not-available.
So, I think this is a two dimensional calculation. There is a standard axis
and a extension axis for the compiler flag, for GCC and clang at least. That
means that we could do something like this:
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
final
override
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9)
list(APPEND CMAKE_CXX14_COMPILER_FEATURES
generalized_lambda_capture
return_type_deduction
)
endif()
# TODO: Add an appropriate GCC version check
list(APPEND CMAKE_CXX98_COMPILER_EXTENSIONS
gnu_template_instantiation
)
# TODO: Add an appropriate GCC version check
list(APPEND CMAKE_CXX14_COMPILER_EXTENSIONS
gnu_generalized_lambda_capture_no_auto
)
Assuming a c++14 only gnu_generalized_lambda_capture_no_auto extension to
allow non-use of auto, as described in section 5.1 here
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf
but not part of the draft standard.
Then, in the implementation of target_compiler_feature,
list(FIND CMAKE_CXX11_COMPILER_FEATURES ${FEATURE_NAME} needs11)
list(FIND CMAKE_CXX11_COMPILER_EXTENSIONS ${FEATURE_NAME} needs11ext)
list(FIND CMAKE_CXX14_COMPILER_FEATURES ${FEATURE_NAME} needs14)
list(FIND CMAKE_CXX14_COMPILER_EXTENSIONS ${FEATURE_NAME} needs14ext)
if(NOT needs14 EQUAL -1)
set(standard 14)
elif(NOT needs14ext EQUAL -1)
set(standard 14)
set(extension TRUE)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
elseif(NOT needs11ext EQUAL -1)
set(standard 11)
set(extension TRUE)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD ${standard})
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_EXTENSION ${extension})
Then, in cmLocalGenerator:
const char *standard = target-GetProperty(CXX_STANDARD);
bool ext = target-GetPropertyAsBool(CXX_EXTENSION);
const char *type = ext ? EXTENSION : STANDARD;
std::string compile_option =
CMAKE_CXX + std::string(standard)
+ _ + std::string(type) + _COMPILE_OPTION;
if (const char *opt =
target-GetMakefile()-GetDefinition(compile_option.c_str()))
{
this-AppendFlags(flags, opt);
}
And:
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11)
set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++11)
endif
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: On 10/09/2013 12:21 PM, Rolf Eike Beer wrote: One thing that is currently unclear if the simulated compiler id stuff from Brad solves the problem of the Clang plugin running with gcc where one would get the gcc version as compiler version but the features are actually depending on the version of the Clang plugin. After the Clang platform files load the GNU files to get the flags they will have to do their own logic to populate the feature lists. They can pass some indicator variable into the GNU files to block the GNU feature lists. The mode of operation of clang under discussion is not a 'normal' mode, but a mode in which clang and gcc aare both used, if I understood what Eike told me. I what is being discussed is either this: http://dragonegg.llvm.org/ or this: http://llvm.org/releases/2.9/docs/CommandGuide/html/llvmgcc.html which I think is deprecated. Eike, can you provide (a link to) more information on the problem you described to me before? Thanks, Steve. -- 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 sources property
Brad King wrote: On 10/10/2013 08:55 PM, Stephen Kelly wrote: Brad King brad.king@... writes: I just checked the VS 6, 9 and 11 IDEs and it is possible to mark a source file as excluded from certain configurations. Those versions represent all the VS generators. If listing all sources and marking each one excluded in specific configurations is sufficient to implement this feature then it should work for VS. Ok, I'll take your word for it :). I don't know enough about the VS generators to implement it for them. Can you compute the set of sources and objects for all configurations before generating any config, and for those that are the same across all configs do not do any special markings and put it in Xcode too? Then things would work except in the true per-config source file case. Yes, I think that's possible. Thanks, Steve. -- 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] C++11 and target_compiler_feature proposal
Brad King wrote: On 10/10/2013 08:07 PM, Stephen Kelly wrote: So, I think this is a two dimensional calculation. There is a standard axis and a extension axis for the compiler flag, for GCC and clang at least. Yes. if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7) set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++11) endif() Will this work for XL too? I assume so. The only flag I'm aware of for XL is -qlanglvl=extended0x, and that is equivalent to -std=c++11 afaik. What are you referring to specifically? I wonder if we should always use the extension flag, unless otherwise specified with set(CMAKE_STRICT_CXX_STANDARD ON)? Because gnu++98 is the GCC default, someone could be using 'gnu template instantiation' in existing code, and then uses CMake to specify the need for variadic_templates, so we add -std=c++11 and boom - no more gnu extensions. As you point out the user would have to have modified the project anyway so at that point they can specify explicitly the default extensions they were using before. Hmm, this might be a sticking point. I'm in favor of sticking close to the defaults of the compiler. The user shouldn't have to tell CMake to use the extension if that is the default for the compiler anyway, just as a penalty for telling CMake about requiring variadic templates. Thanks, Steve. -- 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-LOCATION-policy topic
Brad King wrote:
Steve,
Please extend the CMP0026 message to suggest file(GENERATE)
as a way of putting the target location in a generated file.
Some projects not supporting multi-config generators may
use LOCATION with configure_file.
Done.
Can the policy NEW behavior instead be to return the LOCATION
as a $TARGET_FILE:... generator expression? That would
allow projects to do
if(POLICY CMP0026)
cmake_policy(SET CMP0026 NEW)
endif()
get_property(loc TARGET myexe PROPERTY LOCATION)
add_custom_command(... ${loc} ...)
and work with both CMake 2.8.4 and with whatever release
includes the policy.
I don't know. That seems like a lot of magic and bound to break existing
code.
get_property(loc TARGET myexe PROPERTY LOCATION)
file(WRITE some_script.bat ./${loc})
KDE4 does this:
get_target_property(_executable ${_target_NAME} LOCATION )
set_target_properties(${_target_NAME} PROPERTIES WRAPPER_SCRIPT
${_executable})
and the WRAPPER_SCRIPT is used elsewhere.
Thanks,
Steve.
--
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] C++11 and target_compiler_feature proposal
Stephen Kelly wrote:
I'll try to get a reviewable and first-feature-complete infrastructure
branch together soon.
I've pushed a first iteration of the target_compiler_features branch to my
clone.
For the language specification, I added a prefix to each feature. This
matches the feature tests of clang for standard features, and it is
extensible to extensions with gnuxx_typeof, msvc_sealed etc.
http://clang.llvm.org/docs/LanguageExtensions.html
So far, it only supports the REQUIRED signature of the command.
It will need to get a PUBLIC|PRIVATE specifier, so that the
INTERFACE_COMPILER_FEATURES property can be populated in PUBLIC mode. It
also needs to learn to process generator expressions and how to consume that
property.
Optional features with defines are not yet implemented. I was considering
renaming target_compiler_features to target_required_features and not using
the same command for optional features. Instead I think it might be a good
idea to have a separate command for optional features. Something like:
write_compiler_feature_file(
FILENAME ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
FEATURES cxx_static_assert gnuxx_typeof cxx_variadic_templates
)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
DESTINATION include
)
which writes the file with appropriate content. I don't see any need to use
preprocessor macros for that instead of a file.
I also prototyped a simple way to test clang features as reportedly
supported by clang itself. This won't get us all of the way there with
clang, as some features (such as the gnu typeof extension) do not have
support via __has_extension.
Additionally, I changed my mind on the issue of whether to bump the dialect
to c++11 if the compiler supports the requested feature in c++98 mode. For
example, cxx_variadic_templates would be in CMAKE_CXX98_COMPILER_FEATURES
for GCC and clang, because both support variadic templates even when using
the -std=c++98 dialect. This will still warn, but that's ok, I think.
Note that adding -std=c++11 is almost, but not quite, entirely source
compatible.
For example, this will work with c++98, but errors with c++11:
#define add_prefix(suf) pre_suf
add_prefix(_end);
The feature can be extended for the C standard (89, 99, 11) features too as
well as extensions.
Any comments so far?
Thanks,
Steve.
--
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] Documentation or parse bug
Brad King wrote: On 10/16/2013 02:40 PM, James Bigler wrote: The documentation for target_link_libraries has this description: target_link_libraries(target LINK_PRIVATE|LINK_PUBLIC [[debug|optimized|general] lib] ... [LINK_PRIVATE|LINK_PUBLIC [[debug|optimized|general] lib] ...]) From my understanding I should be able to do this: target_link_libraries(target LINK_PRIVATE lib1 LINK_PRIVATE lib2) however CMake 2.8.11.2 returns: CMake Error at prime/CMakeLists.txt:128 (target_link_libraries): The LINK_PUBLIC or LINK_PRIVATE option must appear as the second argument, just after the target name. Steve, I think this is a parsing problem here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTargetLinkLibrariesCommand.cxx;hb=v2.8.12#l151 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTargetLinkLibrariesCommand.cxx;hb=v2.8.12#l181 It should allow LINK_PUBLIC to occur after another LINK_PUBLIC, and LINK_PRIVATE to occur after another LINK_PRIVATE. Currently it requires that they alternate. Thew newer PUBLIC/PRIVATE/INTERFACE options allow any order and repeats. I pushed the allow-repeated-LINK-keywords to fix this. Thanks, Steve. -- 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] C++11 and target_compiler_feature proposal
Brad King wrote:
Optional features with defines are not yet implemented. I was considering
renaming target_compiler_features to target_required_features
I think target_compiler_features is a clearer name even if it only
supports required features. Please leave room in the signature for
future expansion to optional features just in case.
Ok. When PUBLIC|PRIVATE is part of it, that will be easy even if I remove
REQUIRED.
and not using the same command for optional features. Instead I think
it might be a good idea to have a separate command for optional features.
FWIW, I thought he optional features with macros was quite elegant.
Also that approach didn't require header generation, right?
Correct.
I have
no strong opinion on which approach is better, but here are some
comments.
What is an example use case for optional features?
Adding a move constructor to a class. Many Qt classes have move constructors
and they are inline and bounded by a define.
Another: Define Foo_OVERRIDE to either 'override' or nothing, depending on
the using compiler capability.
What if a header
file selects an available optional feature when included by a .cxx
in the package's libraries, but not when it is later included by an
application? Might that generate an ABI mismatch?
As far as I know, no. Things like r-value references, variadic templates etc
would just be unavailable to the caller if not using a capable compiler.
Things like final and override are not encoded into the ABI afaik. At least
that seems to be the assumption Qt makes.
write_compiler_feature_file(
FILENAME ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
FEATURES cxx_static_assert gnuxx_typeof cxx_variadic_templates
)
IIUC this header will contain hard-coded preprocessor tests and present
the results in preprocessor symbols testable by the project. Shouldn't
it take some kind of namespace prefix for those names? Also this may
need the VERSION interface number previously discussed.
Oops, yes, you're right on both counts. I didn't re-read the previous thread
before writing the above.
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
DESTINATION include
)
If the header is not in the public interface it need not be installed
either.
If the intention is to define Grantlee_OVERRIDE to either 'override' or
nothing depending on the compiler capability, and to use classes using that
define in the interface, then it does have to be installed.
which writes the file with appropriate content. I don't see any need to
use preprocessor macros for that instead of a file.
That will also simplify consuming an interface without CMake because no
magic addition of preprocessor definitions will be needed.
Yes.
I also prototyped a simple way to test clang features as reportedly
supported by clang itself. This won't get us all of the way there with
clang, as some features (such as the gnu typeof extension) do not have
support via __has_extension.
Neat. I see no reason Modules/FeatureTests/clang_feature_tests.cxx
can't be just Modules/Compiler/clang_feature_tests.cxx. For those
features not covered by __has_extension we can list them explicitly.
You'll also have to deal with cases when CMAKE_CXX_COMPILER is not
set. It should always be set at this point but we need to fail with
a readable explanation if it is not.
Ok.
Any comments so far?
Should we memoize the language feature lists as std::set at the end of
cmGlobalGenerator::EnableLanguage to make lookup faster and avoid projects
corrupting the lists?
I'm not sure. We might not list a feature which a compiler has, either
because the compiler release is newer than the cmake release, or because the
compiler is unknown to us.
In that case, being able to use
list(APPEND CMAKE_CXX_COMPILER_FEATURES cxx_variadic_templates)
would be useful.
Thanks,
Steve.
--
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 --find-package (was: Roadmap to CMake 3.0)
Brad King wrote: On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES variable (or a slight variation) being set after a successful find_package(Foo): http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the future there will be Find-modules which typically export one of (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that too, and a big number, probably majority, of Config.cmake files, which do not export such variables. The only chance I see would be to simply collect all library targets and return what they provide, but this doesn't feel good. I would have much prefered using a clear interface like the Foo_LIBRARIES variable. Perhaps we need to establish a convention for find modules and package configuration files to interact with --find-package mode. I have no thoughts on the specifics of how that would work though. A new, similar --find-target mode or similar may be more appropriate: cmake --find-target --package Qt5Widgets --target Qt5::Widgets ... # KF5Config exports 3 independent targets: cmake --find-target --package KF5Config --target KF5::ConfigCore ... cmake --find-target --package KF5Config --target KF5::ConfigGui ... cmake --find-target --package KF5Config --target KF5::ConfigWidgets ... Thanks, Steve. -- 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] C++11 and target_compiler_feature proposal
Brad King wrote:
On 10/21/2013 04:05 PM, Stephen Kelly wrote:
I'm still not sure that generating a header specific to the compiler (ID
and version) is a good idea.
[snip]
So, I think maybe it would make sense to list features separately, and if
someone does this:
I thought we had reached that conclusion before. See the bottom of
this message:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7809
Anyway, we agree.
Further-on, you responded:
Why do you need to check features of a compiler not currently enabled?
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
FEATURES cxx_final cxx_override
)
Yes, though it still needs the mandatory VERSION.
I thought the VERSION would be optional and would default to
CMAKE_MINIMUM_REQUIRED_VERSION:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7812
the generated header would look something like this:
Yes.
Actually it appears this header will duplicate most of the compiler
feature
knowledge encoded in the CMake platform modules we discussed before. I
wonder if we can come up with a representation that can be used to
generate both.
Probably. However, that means that we either shouldn't use the clang
__has_feature() test that I implemented, or we'll have to duplicate all of
that information anyway.
Thanks,
Steve.
--
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] Fwd: CMake System Prefix Path
Forwarding this for Ben. Would it be reasonable to have a way to not add the CMAKE_INSTALL_PREFIX to the CMAKE_SYSTEM_PREFIX_PATH? The install prefix is not cleared before the CI build on build.kde.org because the dependency graph is quite large (everything depends on Qt, most things depend on kdelibs, some things depend on kdepimlibs etc). Successful builds are uploaded to a master server and build nodes will re-download that if they have no version of the dependency. That re-download can be huge and take significant time, so it is avoided by also not clearing the install prefix on each of the build nodes. Is the only solution to this as Ben describes with passing NO_CMAKE_SYSTEM_PATH to CMake? Thanks, Steve. Original Message Subject:CMake System Prefix Path Date: Tue, 22 Oct 2013 17:03:26 +1300 From: Ben Cooksley bcooks...@kde.org To: Stephen Kelly steve...@gmail.com Hi Stephen, It has between pointed out to me on IRC that CMake automatically adds the install prefix path (CMAKE_INSTALL_PREFIX) to CMAKE_SYSTEM_PREFIX_PATH - which is included in the paths searched. This is rather unfortunate as it interferes in our CI system - we rely on CMake searching only normal system paths (like /usr) and the paths we specify (via CMAKE_PREFIX_PATH) in order to ensure our builds are clean. This means kdelibs[frameworks] builds have been succeeding when they should be failing. Is there any way around this issue other than ensuring /usr and /usr/local are included in CMAKE_PREFIX_PATH, and passing NO_CMAKE_SYSTEM_PATH to CMake? (As an aside, it seems that something in the stack Grantlee uses is definitely modifying CMAKE_SYSTEM_PREFIX_PATH as it contains /srv/jenkins/install/linux/x86_64/g++/common/shared - which is not the install prefix. Thanks, Ben -- 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: CMake System Prefix Path
Alexander Neundorf wrote: Is the only solution to this as Ben describes with passing NO_CMAKE_SYSTEM_PATH to CMake? Is everything installed into its own separate directory, or everything into one common install directory ? Everything is installed to a separate directory, and each one is added to the relevant environment variables. So, build.kde.org *could* clear the install directory, but that would mean that if the build of kdelibs (for example) failed, the build of amarok (for example) on the same build node would first have to transfer the cached install tree from the master node. As that takes time, it is preferred to avoid that. Therefore the install tree is not cleared. Thanks, Steve. -- 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] C++11 and target_compiler_feature proposal
Brad King wrote: CMAKE_CXX_COMPILER is always set to the proper full path these days, even in the IDE generators, so I wonder if we could actually run it against the header file to detect the features available for the current compiler instead of hard-coding a table in the platform information files. Then the checks would all be done in one place via the preprocessor and __has_feature if available. I've implemented this and merged it to next for dashboard testing. I haven't yet looked into how to create docs for the new WriteCompilerDetectionHeader module. Thanks, Steve. -- 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] C++11 and target_compiler_feature proposal
Brad King wrote: On 10/23/2013 05:59 PM, Stephen Kelly wrote: CMAKE_CXX_COMPILER is always set to the proper full path these days, even in the IDE generators, so I wonder if we could actually run it against the header file to detect the features available for the current compiler instead of hard-coding a table in the platform information files. Then the checks would all be done in one place via the preprocessor and __has_feature if available. I've implemented this and merged it to next for dashboard testing. Please see the hythloth.kitware Linux64-gnu build entry on the dashboard for some documentation errors reported by sphinx-build. Also when you run the compiler you need to capture all stdout/stderr so that it never leaks through to the user-visible cmake configuration output. The RunCMake.* tests that failed last night were mostly due to compilers writing to stderr even when nothing is wrong and therefore messing with the expected output matching. Should be all fixed now. Thanks, Steve. -- 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] Major.Minor version install directories
Hello,
My install prefix currently looks something like this:
l -1 /home/stephen/dev/prefix/qtbase/kde/doc/
cmake-2.8/
cmake-2.8.12.20131023-g07324-dirty/
cmake-2.8.12.20131023-g10e02-dirty/
cmake-2.8.12.20131023-g1bfc2/
cmake-2.8.12.20131023-g3dec3/
cmake-2.8.12.20131023-g5a601/
cmake-2.8.12.20131023-g85363/
cmake-2.8.12.20131023-g8b987/
cmake-2.8.12.20131023-g8c74f-dirty/
cmake-2.8.12.20131023-gb98eb/
cmake-2.8.12.20131023-gd050b/
cmake-2.8.12.20131023-gf2f63-dirty/
cmake-2.8.12.20131024-g09257/
cmake-2.8.12.20131024-g09257-dirty/
cmake-2.8.12.20131024-g42ee2/
cmake-2.8.12.20131024-gabca/
cmake-2.8.12.20131024-ge6df9/
with similar stuff in other places in the prefix, and in other prefixes.
Can we switch those install directories back to using
set(CMAKE_DATA_DIR_DEFAULT
share/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR})
etc?
Thanks,
Steve.
--
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] Review request: Qt-auto-generators
Alexander Neundorf wrote: On Thursday 24 October 2013, Stephen Kelly wrote: Hi, I've pushed the Qt-auto-generators topic to stage. This topic was discussed here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7936 I have tested it with ports of KDE Frameworks and GammaRay to use the features. Alex, could you also review the topic please? Looks good in general. Just some nitpicking: this is still Qt-specific, so I would prefer to have something related to Qt in the names of the target properties and output and maybe also if the generated files instead of AUTOGEN_TARGETS_FOLDER, AUTOGEN: and and AutogenInfo.cmake. I thought about that but couldn't think of better, more suitable names. Also, just because it's Qt-specific now doesn't mean it always will be. If there's a reason for something similar relating to another tool, another rename would be needed. I'd prefer to stick with Autogen*. Thanks, Steve. -- 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
